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Chapter  1 

Introduction 


1.1  Purpose 

The  Clemson  Interactive  Planner  (C€IP  )  is  a  software  decision  support  tool 
useful  in  planning  the  use  of  pinning  and  cutting  resources  in  a  cutting  room 
This  manual  describes  how  to  use  CflP  . 

The  current  version  of  the  software  is  implemented  in  Objectworks\Smal!- 
talk,  an  implementation  of  the  SmalitaJk-80  programming  language  that  is  avail¬ 
able  on  a  variety  of  platforms,  including  the  IBM  PC,  Apple  Macintosh,  and 
Sun  SPARCStation.  The  current  implementation  was  done  on  a  Macintosh  and 
the  examples  in  this  manual  are  taken  from  that  environment.  Ail  environments 
are  essentially  the  same;  only  the  “look  and  feel”  of  the  windowing  system  varies 
across  platforms. 


1.2  Scope 

The  information  in  this  document  describes  the  the  current  implementation 
developed  under  the  sponsorship  of  the  Defense  Logistics  Agency  and  Clemson 
Apparel  Research.  The  current  implementation  is  a  prototype  and  contains  only 
a  relative  few  of  the  features  the  final  system  should  contain.  It  is  not  suitable 
for  production  use,  primarily  because  the  user  interface  is  primitive,  but  also 
because  some  of  the  class  definitions  required  are  incomplete. 

This  prototype  has  been  produced  as  part  of  a  research  effort  to  use  object- 
oriented  technologies  to  adapt  simulations  easily  to  a  wide  variety  of  cutting 
room  environments.  The  implementation — and  this  manual — focus  on  those 
portions  that  have  been  implemented  and  provide  a  look  at  how  a  production 
system  might  look.  Please  note  that  software  still  needs  to  be  written.  The 
information  in  this  manual  corresponds  to  the  state  of  the  system  at  the  end 
of  current  funding  of  the  project  under  which  it  was  developed.  This  document 
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and  the  document  COP  System  Architecture  serve  to  document  th-  status  ot' 
the  project  at  that  time. 

Instructions  on  installing  the  prototype  system  are  provided  in  Appendix  A 


1.3  Background 

COP  is  a  simulation  system  intended  as  a  tool  for  assisting  in  the  pianiiing  of 
the  allocation  of  resources  in  a  cutting  room.  Pinning  and  cutting  operations  in 
an  apparel  plant  are  responsible  for  producing  the  pieces  of  fabric  that  go  into 
the  construction  of  an  apparel  item.  These  operations  are  performed  in  a  cutting 
room  using  a  variety  of  ai  .omatic  and  manually-operated  machines  designed  to 
spread  fabric  in  multiple  layers  and  cut  them.  .A  cutting  room  manager  must 
make  a  variety  of  decisions  with  respect  to  how  the  various  resources — operators, 
workstations,  and  materials — are  scheduled  to  produce  cut  bundles  on  time  and 
at  low  cost. 

The  cutting  room’s  function  includes  the  processing  cf  n.'i:,  of  fabric  into  the 
pieces  required  for  a  garment’s  manufacture.  A  typical  im”  's  dress  shirt,  for 
example,  comprises  about  sixteen  pieces  that  are  sewn  toge.  .er  before  buttons 
are  attached.  Each  of  these  pieces  is  produced  by  the  cutting  :  ■  om  in  accordance 
with  a  set  of  requirements  derived  from  a  wide  range  of  (.■.•■rameters  such  as 
fabric,  fabric  pattern,  garment  size,  and  garment  style.  Tiic  lu  imary  goal  of  the 
cutting  room  manager  is  to  supply  these  pieces  by  the  time  r^.ey  are  needed  by 
the  sewing  room,  but  to  supply  them  at  the  lowest  cost  botii  in  terms  of  labor 
and  of  fabric  utilization  (i.e.,  minimize  the  amount  of  scrap  i 

The  scheduling  of  cutting  room  resources  is  a  difficult  p'.  "ilem  complicated 
by  many  factors.  A  cutting  room  contains  equipment  designed  to  spread  and 
cut  fabric.  Machines  have  been  developed  to  spread  fabric  in  multiple  layers 
on  a  table.  Other  machines  have  been  developed  to  cut  through  the  layers  of 
spread  fabric,  thereby  producing  dozens  of  cut  pieces  at  a  time.  Some  of  these 
machines  are  operated  by  hand  and  others  are  operated  under  computer  control. 
A  spread  up  to  sixty  feet  long  can  be  fed  automatically  through  a  cutter  under 
computer  control  to  produce  the  cut  pieces  processed  by  the  sewing  rooms. 
Some  specialized  dye  cutters  can  both  spread  and  cut,  needing  only  a  single 
operator  to  monitor  the  machine. 

A  variety  of  machines  can  be  found  in  a  typical  cutting  room.  Figure  1.1 
shows  a  sample  cutting  room  with  three  tables  supporting  automatic  spreading, 
a  BITE  cutter  that  can  be  positioned  at  the  end  of  any  of  these  three  tables  and 
process  a  spread  of  arbitrary  length,  a  table  that  supports  automatic  spread¬ 
ing  and  pinning  but  manual  cutting,  and  a  smaller  table  that  supports  manual 
spreading  and  manual  cutting.  Pinning  is  required  for  g.armenls  that  have  "en¬ 
gineered  placements” — for  example,  plaid  trousers  for  which  the  plaid  pattern 
must  match  between  the  left  and  right  halves  of  the  garment,  meaning  that  the 
cuts  must  be  matched  to  the  pattern.  Pins  are  used  to  keep  the  pattern  aligned 
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Figure  1.1:  A  sample  cutting  room.  A,  B,  C;  tables  with  automatic  spreaders; 
D:  a  BITE  cutter  that  can  be  positioned  at  the  end  of  any  of  three  tables 
and  process  a  spread  of  arbitrary  length;  E:  a  table  that  supports  automatic 
spreading  and  pinning  but  manual  cutting;  and  F:  a  smaller  table  that  supports 
manual  spreading  and  manual  cutting. 


on  all  of  the  layers  of  fabric  in  a  spread. 

Among  the  decisions  that  a  cutting  room  manager  makes  are: 

•  which  operator  to  assign  to  which  task.  Each  operator  has  different  skills 
and  efficiencies  that  can  be  applied  to  the  tasks  that  need  to  be  done. 

•  whether  operators  should  be  scheduled  to  work  overtime  or  perhaps  whether 
another  shift  should  be  added.  If  the  workload  is  heavy,  then  the  cutting 
room  might  have  to  work  more  hours.  Overtime  raises  production  costs, 

•  how  to  reallocate  resources  when  an  operator  doesn’t  show  up  for  work, 
an  operator  leaves  work  early,  or  a  machine  goes  down  une.\pectedly. 

•  which  fabric  to  spread  on  which  table.  Once  a  spread  is  begun,  it  cannot 
be  moved  to  another  table  without  introducing  wrinkles,  although  most 
spreads  can  be  slid  to  another  part  of  the  same  table.  Most  spreads  do 
not  occupy  the  entire  length  of  a  table  and  more  than  one  spread  can 
be  placed  on  a  table.  However,  if  the  cutting  is  to  be  performed  by  an 
automatic  cutter,  then  the  cutting  can  only  be  done  in  the  order  that  the 
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spreads  lie  on  the  table  since  the  cutter  is  fed  a  spread  from  one  end  of 
the  spreading  table.  Often  a  style — for  example,  jeans,  tee  shirts,  dress 
shirts,  etc. — requires  several  fabrics  and  spreads.  Consider  a  shirt  with  a 
striped  front  and  a  polka-dot  collar.  Spreading  must  be  planned  such  that 
the  cutting  for  all  the  striped  parts  can  be  done  near  the  time  that  the 
cutting  for  all  the  polka-dot  parts  is  done  so  that  the  shirts  can  be  sewn 
without  a  need  to  store  any  cut  parts  for  them  for  very  long. 

Some  spreads  are  limited  to  certain  tables  because  of  the  fabric  qualities 
or  how  cutting  must  be  done.  For  example,  only  one  automatic  spreader 
in  a  cutting  room  might  be  suitable  for  knit  fabrics  or  a  pinning  table 
must  be  used  for  spreading  a  plaid  fabric  to  meet  engineered  placement 
specifications. 

•  which  fabric  to  spread  next.  Some  spreads  take  a  long  time — for  example, 
spreads  that  require  pinning  for  engineered  placements,  spreads  that  have 
many  plies,  spreads  of  very  thin  fabrics,  or  spreads  that  cannot  be  done 
using  automatic  spreading  equipment — and  tie  up  resources  for  a  long 
period  of  time. 

•  how  much  variance  to  use  for  a  cut.  If  the  fabric  available  is  not  sufficient 
to  produce  an  exact  order,  a  decision  must  be  made  concerning  how  much 
more  or  less  to  cut.  If  a  relatively  small  amount  of  fabric  will  be  left  after 
a  cut,  then  a  decision  must  be  made  concerning  how  many  more  pieces  lo 
cut  (and  which  size(s))  i.i  order  to  minimize  scrap. 

•  which  production  orders  can  be  combined.  Fabric  utilization  can  be  im¬ 
proved  by  combining  two  or  more  production  orders  that  use  the  same 
fabric  as  long  as  there  is  sufficient  fabric  available.  This  combination  can 
be  achieved  either  by  placing  markers  end-to-end  on  a  spread  or  by  com¬ 
bining  the  individual  markers  into  a  single  marker'.  Fabric  utilization  is 
usually  improved  if  the  latter  technique  is  used,  but  this  technique  takes 
more  lead  time  in  order  to  produce  a  marker.  Lying  markers  end-to-end 
produces  fabric  savings  by  reducing  waste  on  the  cut  ends  of  a  spread. 

Production  orders  requiring  the  same  cuts  can  sometimes  be  incorporated 
into  a  single  spread.  This  is  desirable  because  it  reduces  cutting  time  and 
can  save  fabric. 

•  which  spread  to  cut  next.  As  illustrated  in  figure  1.1,  a  cutter  may  be 
shared  by  multiple  spreading  tables.  A  decision  must  be  made  as  to  which 
spread  to  cut  based  on  the  time  that  will  be  required  for  cutting  and 
subsequent  needs  for  the  spreading  resources  that  will  be  freed  up  after 
the  spread  is  cut. 

'a  marker  is  a  layout  of  the  pieces  to  be  cut  from  a  given  length  of  fabric,  usually  plotted 
on  a  large  piece  of  paper  and  placed  atop  a  spread  to  identify  the  cuts.  Labels  printed  on  the 
paper  pieces  identify — or  mart — the  cuts  that  are  produced. 
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•  what  to  do  if  a  production  order  for  a  sample  arrives  The  production 
of  sample  garments  generally  takes  priority  over  regular  production  and 
preempts  jobs  in  progress. 

The  development  of  a  cutting  plan  for  some  period  of  time — for  example, 
a  day  or  a  week — is  an  art  generally  based  on  a  cutting  manager’s  experience 
Good  cutting  room  managers  are  difficult  to  find  and,  as  a  relatively  scarce 
commodity,  difficult  to  keep  at  a  plant.  Our  goal  is  to  help  a  cutting  room 
manager  make  decisions  about  cutting  room  resource  utilization  such  that  costs 
are  minimized  and  fabric  utilization  is  maximized.  Our  .solution  is  a  decision 
support  tool  that  simulates  the  cutting  room  in  order  to  predict  the  outcome  of 
various  plans. 


Chapter  2 

Running  a  Simulation 


In  this  chapter,  we  explain  how  ii  create  a  scenario.  A  scenario  consists  of  a 
cutting  room  and  a  plan  for  allocating  the  resources — equipment,  materials,  and 
operators — to  the  work  assignments  to  be  accomplished. 


2.1  Creating  a  Scenario 

Putting  a  scenario  together  requires  describing  a  cutting  room,  defining  re¬ 
sources,  and  creating  a  plan  to  be  used  as  the  basis  fo.  a  simulation.  In  tlii.s 
section,  we  will  describe  the  construction  of  a  scenario  involving  a  cutting  room 
with  two  tables  that  can  be  used  for  both  spreading  and  cutting.  Three  op¬ 
erators,  designated  as  Huey,  Dewey,  and  Louie,  are  available  for  work.  Rolls 
of  fabric  are  avciilable  for  the  various  tasks  to  be  performed.  Construction  of 
other  scenarios  parallel  construction  of  this  example.  [The  file  scenario.txt 
on  the  distribution  diskette  contains  the  code  necessary  to  construct  and  run 
this  scenario.] 

A  scenario  is  constructed  by  a  sequence  of  Smalltalk  statements.  The  cur¬ 
rent  implementation  does  not  include  an  explicit  class  to  represent  a  scenario, 
though  perhaps  such  a  class  should  be  provided.  Nor  does  this  implementation 
provide  any  interactive  support  for  describing  a  cutting  room'.  The  approach 
to  defining  a  scenario  in  Smalltalk  provides  greater  flexibility  during  prototype 
development,  but  probably  more  flexibility  than  is  required  for  the  typical  user 
VVe  expect  that,  in  practice,  the  need  to  use  Smalltalk  will  be  supplanted  by  the 
use  of  interactive  tools  and  dictionaries  of  resources. 

'  Ideally,  a  cutting  room  would  be  described  by  arranging  pieces  of  equipment  on  an  .irc.a 
of  a  computer  monitor  screen. 
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Resources 


The  first  step  in  the  construction  of  a  scenario  is  the  definition  of  the  resources. 
Resources  comprise  the  equipment,  operators,  '.nd  rolls  of  fabric  and  other  ma¬ 
terials  that  are  found  in  the  cutting  room. 

The  segment  of  code  below  defines  the  resources  in  the  example  scenario 


Allocate  equipment  resources: 


tablel  :=  Table  makePair:  Table  1' 
table2  :=  Table  makePair:  Table  2' 
equipment  ;=  OrderedCollection 
with:  tablel  with:  table2. 


We  define  the  two  pieces  of 
equipment  and  put  them  in 
an  ordered  collection.  This 
collection  will  be  used  to 
establish  priorities  in  the 
simulation,  but  the  ordering 
IS  really  unimportant. 

The  message  takes  a 
siring  designating  the  name 
of  the  table  as  its 
argument.  The  message 
designation  is  taken  from 
DEVS,  and  is  admittedly 
not  very  user-friendly. 
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Define  three  operators,  Huey,  Dewey,  and  Louie 


huey  :=  Operator  new 
name:  Huey’, 
number:  1: 
status:  #idle: 
skills:  (Dictionary  new 
at  tablel  put.  1  00. 
at  table2  put  1  00: 
yourself), 
image:  (Image 
extent.  16  <S  16 
depth  1 

palette.  MappedPalette  whiteBlack 
bits  #( 

16r01  16rc0  16r02  16r20 
16r04  16rl0  16r09  16r48 
16r08  16r08  16r09  16rc8 
16r05  I6rd0  16r02  I6r20 
16r01  16rc0  16r07  16r70 
16rl8  16r0c  16r61  16r43 
I6r45  i6f51  16r49  16rc9 
16r49  16r49  16r49  16r49] 
pad,  16)  reflectedInX. 
yourself 


Define  ope  ator  Huey, 
employee  number  1  hantig 
100%  efficiency  at  both 
tables  The  tmaye  is  used 
lu  represent  this  operator 
on  the  screen  {Refer  to 
Object  wo  rks  document  o  Ik'  n 
for  details  on  imaye 
creation  J 
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dewey  :=  Operator  nev* 
name;  Dewey’, 
number:  2; 
status:  #idle. 
skills:  (Dictionary  new 
at:  tablel  put  1  00: 
at:  table2  put  1  00. 
yourself); 
image:  (Image 
extent:  16  16 

depth:  1 

palette:  MappedPalette  whiteBlack 
bits:  #( 

16r01  16rc0  16f02  16r20 
16r04  16rl0  16r09  16r48 
16r08  16r08  16r09  16rc8 
16r05  16rd0  16f02  16r20 
16r01  16rc0  16r07  16r70 
16rl8  16r0c  I6r60  16rc3 
16r45  16r51  16r49  I6r49 
16r49  16r49  16r48  16rc9  ] 
pad:  16)  reflectedInX. 
yourself 


Stniilariy.  detini  uprra.'or 
Deuty 
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louie  =  Operator  new 
name:  Louie': 
number;  3; 
status:  #idle: 
skills:  (Dictionary  new 
at:  tablel  put:  1.00: 
at:  table2  put:  1  00: 
yourself); 
image:  (Image 
extent;  16  3  16 
depth:  1 

palette;  MappedPalette  whiteBlack  And  oprratar  Louie 

bits:  #( 

16r01  16rc0  16r02  16r20 
16r04  16rl0  16r09  16r48 
16r08  16r08  16r09  I6rc8 
16r05  16rd0  16r02  16r20 
16r01  16rc0  16r07  16r70 
16rl8  16r0c  I6r60  16r43 
16r44  16r51  16r48  16r49 
16r48  I6r49  I6r49  16rc9j 
pad;  16)  reflectedInX. 
yourself. 

A  resource  collection  is  a 

operators  :=  ResourceCollection  collection  of  resources  that 

with;  huey  with:  dewey  with  louie.  ,s  able  to  display  itself  as  a 

collection  irj  a  vieio. 
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Create  some  fabrics  and  rolls  of  fabrics: 


(cotton  ;=  Material  new) 

description:  '100%  cotton’ 

redCotton  :=  Fabric 

color;  Color  red  weave:  nil 
weight:  1  thickness:  0.0625  inches 
material:  cotton  defectRate:  0.0. 
greenCotton  ;=  Fabric 

color:  Color  green  weave:  nil 
weight:  1  thickness:  0.0625  inches 
material;  cotton  defectRate:  0.0. 
blueCotton  :=  Fabric 

color:  Color  blue  weave;  nil 
weight;  1  thickness:  0.0625  inches 
material:  cotton  defectRate:  0.0. 


greenRoll  :=  FabricRoll 
fabric:  greenCotton 
length;  500  feet  width:  54  inches. 
biueRoll  :=  FabricRoll 
fabric:  blueCotton 
length:  200  feet  width;  54  inches. 
redRoll  :=  FabricRoll 
fabric;  redCotton 

length;  1000  feet  width:  60  inches. 

greenRoll  name;  ‘green  cotton'. 
biueRoll  name:  'blue  cotton'. 
redRoll  name;  'red  cotton' 


materials  ;=  ResourceCollection 

with;  greenRoll  with:  biueRoll  with: 


Alt  fabrics  are  100%  cotton 


Create  three  rolls  of  cotton, 
one  green,  one  blue,  and 
one  red. 


The  length  and  width  of 
each  roll  is  specified,  and 
each  roll  is  given  a  name. 
Note  that  units  of  feel, 
yards,  and  inches  are  used. 
All  lengths  must  include 
the  units  of  measure. 


Put  the  rolls  of  fabric  in  a 
redRoll.  resource  collection. 


2.1.1  Tasks  and  Work  Assignments 

Once  resources  have  been  defined,  they  can  be  used  in  work  assiirnments.  A 
work  assignment  is  the  association  of  a  task  with  the  equipment,  operators,  ami 
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materials.  There  are  currently  four  kinds  of  tasks  in  CflP  ;  spreading,  cultuig, 
moving,  and  bundling.  Each  task  has  a  different  class  defined  for  it.  The  results 
of  a  work  assignment  is  represented  by  a  ticket.  So,  for  example,  if  fabric  is 
to  be  spread  and  then  cut,  the  result  of  the  spreading  task  is  associated  with 
a  ticket  and  that  ticket  serves  as  one  of  the  materials  required  for  the  cutting 
task.  Tickets,  among  other  things,  prescribe  an  ordering  to  work  assignments 


ticketl  :=  Ticket  new:  Ticket  1'. 
ticket2  :=  Ticket  new:  'Ticket  2'. 
tickets  :=  Ticket  new:  'Ticket  3'. 


Create  three  tickets  noiv  for 
convenience. 


spreadingTaskl  :=  SpreadingTask 

spreadTemplate  (SpreadTemplate 
new:  4  layersOf:  greenCotton 
ofWidth;  54  inches 
ofLength:  60  feet) 
rolls:  (ResourceCollection 

with:  greenRoll  with:  blueRoll) 
marker:  nil. 

spreadingTask2  :=  SpreadingTask 

spreadTemplate;  (SpreadTemplate 
new:  10  layersOf:  redCotton 
ofWidth:  60  inches 
ofLength:  30  feet) 

rolls:  (ResourceCollection  with:  redRoll) 
marker:  nil. 

spreadingTask3  :=  SpreadingTask 

spreadTemplate:  (SpreadTemplate 
new:  6  layersOf:  redCotton 
ofWidth:  60  inches 
ofLength:  3  yards) 

rolls:  (ResourceCollection  with:  redRoll) 
marker:  nil. 

spreadingTask4  :=  SpreadingTask 

spreadTemplate:  (SpreadTemplate 
new:  6  layersOf:  biueCotton 
ofWidth:  54  inches 
ofLength:  50  feet) 

rolls:  (ResourceCollection  with:  blueRoll) 
marker:  nil. 


There  are  four  tasks  to  be 
performed: 

•  spread  4  layers  of 
green  cotton 

•  spread  10  layers  of 
red  cotton 

•  spread  6  layers  of  red 
cotton 

•  spread  6  layers  of 
blue  cotton 

A  spread  template  defines 
the  length,  width,  number 
of  plies,  and  composition  of 
each  ply. 
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2.1.2 


Plans 


Once  the  tasks  are  set  and  the  resource  sets  are  defined,  a  plan  is  constructed. 
A  plan  comprises  a  sequence  of  work  assignments,  each  designating  a  task,  a 
set  of  one  or  more  operators  to  work  together  on  the  task,  and  a  workstation 
at  which  the  tcisk  is  o  be  performed.  A  workstation  is  a  section  of  a  piece  of 
equipment  and  can  vary  from  assignment  to  assignment.  For  e.xampie,  a  spread 
might  be  constructed  on  two-thirds  of  the  left  end  of  a  table  and  another  spread 
might  be  constructed  on  the  right  two-thirds.  Two  workstations  at  the  same 
table  are  involved.  (Obviously,  one  of  these  tasks  cannot  be  started  until  the 
other  spread  has  beer,  moved.  Thus,  the  demand  for  workstations  at  the  same 
piece  of  equipment  specifies  a  partial  ordering  of  work  assignments. 

A  workstation  is  designated  as  two  percentages  of  the  width  and  length  of  a 
piece  of  equipment,  which  is  always  assumed  to  have  some  rectangular  shape. 
This  area  is  referred  to  as  a  section.  Thus,  the  entire  equipment  can  be  a  single 
workstation,  designated  as  width:  0-100%,  length:  0-100%.  The  left  half  of  a 
workstation  is  designated  as  width:  0-100%,  length:  0-50%. 

A  plan  must  be  given  a  start  time.  This  time  sets  the  conte.xt  for  a  simulation 
run.  The  time  is  significant  because  workers  have  work  schedules  (default  is 
8:00  A.M.  to  5:00  P.M.  with  an  hour  for  lunch  at  noon  and  15-minute  breaks  at 
10.00  and  3:00). 
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plan  :=  Plan  new. 
plan  start  Time;  (SimulationTime 
date;  (Date  newOay;  1 

month;  ^October  year;  1992) 
time;  (Time  fromSeconds;  0)). 
wal  :=  WorkAssignment 
workstation;  (Workstation 
at:  tablel  section: 

(Section  origin:  0  0  corner:  0.5  1)) 
operators:  (Set  with;  huey) 
task:  spreadingTaskl 
ticket:  ticketl. 
wa2  :=  WorkAssignment 
workstation:  (Workstation 

at:  tabie2  section:  Define  four  work 

(Section  origin:  0.25  0.25  assignments,  one  for  each 

corner;  0.75  0.75)  )  task. 

operators:  (Set  with;  louie) 
task:  spreadingTa$k2 
ticket:  ticket2. 
wa3  :=  WorkAssignment 

workstation:  (Workstation  at:  table2) 
operators;  (Set  with;  dewey) 
task:  spreadingTa$k3 
ticket:  ticket3. 
wa4  :=  WorkAssignment 
workstation:  (Workstation 
at:  tablel  section: 

(Section  origin;  0.5  0  corner:  1  1)) 
operators:  (Set  with:  huey) 
task:  spreadingTask4 


plan  add.  wal:  add.  wa2;  add:  wa3;  add:  wa4.  assignments 

rn  a  plan.  Order  matters. 


2.1.3  Cutting  Room 

The  final  step  in  the  construction  of  a  scenario  is  the  placing  of  the  plan  and 
resources  in  a  cutting  room.  The  cutting  room  itself  is  a  DEVS  model,  and  the 
argument  to  makePair:  is  the  name  of  the  cutting  room. 
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cuttingRoom  ;=  (CuttingRoom  makePair:  "ACME  Cutting  Room’ 
containing:  equipment 
operators:  operators 
materials:  materials). 

cuttingRoom  plan:  plan. 


2.1.4  Simulation  Runs 

A  simulation  run  is  created  by  associating  a  root  coordinator  with  the  cutting 
room  model,  specifying  a  starting  time  for  the  simulation,  and  specifying  the 
time  at  which  simulation  should  stop.  Finally,  the  model  is  associated  with 
a  simulation  window,  an  instance  of  the  class  SimulationRunView,  from  which 
simulation  is  controlled  as  explained  in  Section  Running  Simulations. 

scenario  :=:  RootCoordinator  new:  'RC:ACME  Cutting  Room', 

startTime  :=  (SimulationTime 

date:  (Date  newDay:  1  month:  #October  year:  1992) 
time:  (Time  fromSeconds:  0)). 

scenario 

StartTime:  startTime; 

timelimit:  (startTime  addDuration:  5  days); 
linkToParent;  (cuttingRoom  processor). 

Cursor  wait 

showWhile:  [SimulationRunView  tryOn;  scenario  ]. 


2.2  Running  Simulations 


We  have  just  described  the  specification  of  a  scenario  and  the  method  for  cre¬ 
ating  of  a  window  to  control  s.muiation.  The  simulation  v'lc’.v  provided  by  the 
current  implementation  is  shown  in  Figure  2.1, 

The  window  labeled  “CUP:  RC:ACME  Cutting  Room"  contains  the  follow¬ 
ing  components: 

•  a  Restart  button  used  to  reset  all  the  models  in  the  run. 

•  a  Go  button  used  to  start  or  resume  a  simulation  run. 

•  a  Pause  button  used  to  interrupt  a  simulation  run  during  execution. 
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Figure  2.1;  The  initial  screen  for  a  simulation  run. 
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•  a  Step  button  used  to  single-step  a  simulation,  meaning  to  execute  one 
iteration  of  the  loop  being  performed  by  the  root  coordinator  controlling 
the  simulation. 

•  a  text  view  (under  the  buttons)  that  provides  the  time  of  the  last  simula¬ 
tion  event  and  of  the  next  simulation  event.  These  values  are  maintained 
by  the  root  coordinator. 

•  a  set  of  views,  one  for  each  atomic  model  in  the  system- — that  is,  one  for 
the  various  components  of  the  cutting  room.  The  default  arrangement 
is  for  the  planner  and  dispatchers  to  show  across  the  top  line  and  for 
the  equipment  to  show  across  the  bottom  line.  Each  view  is  labeled  by 
its  name  and  each  provides  a  graphical  representation  of  its  current  sta¬ 
tus.  All  models  show  the  values  of  e,  x,  y,  and  sigma  associated  with  the 
management  of  atomic  models.  Below  this  information,  each  view  reflects 
model-specific  information: 

—  Oscar  is  a  planner  and  shows  the  current  plan.  [A  graphical  repre¬ 
sentation  would  be  preferable  as  would  a  scrollable  view,  but  time 
did  not  permit  their  implementation.) 

-  Drop  Area  is  a  dispatcher  of  materials.  The  three  cylindrical  objects 
shown  represent  rolls  of  fabric.  The  horizontal  representation  of  each 
roll  shows  that  the  roll  is  currently  not  in  use.  A  vertical  orientation 
designates  that  the  roll  is  in  use  (or  about  to  be  since  more  than 
one  iteration  of  the  root  coordinator  can  apply  to  a  given  simulation 
time). 

-  Break  Area  is  a  dispatcher  of  operator  resources.  The  three  icons 
represent  Huey,  Dewey,  and  Louie.  These  operators  are  shown  idle 
since  they  are  outlined  in  black. 

-  Table  1  shows  a  rectangular  area  shaded  gray.  This  represents  the 
surface  of  the  table.  An  active  workstation  at  a  table  is  shown  shaded 
black.  The  nil  showing  in  the  upper  right-hand  corner  reflects  the 
current  phase  of  the  model. 

—  Table  2  is  similar  to  Table  1  and  is,  m  fact,  of  the  same  class. 

When  a  window  for  a  simulation  run  is  first  displayed,  no  restart  has  been 
done  on  the  root  coordinator.  Consequently,  all  values  for  simulation- 
related  information  shows  nil. 

Figure  2.2  shows  the  window  after  the  Restart  button  has  been  pressed.  Note 
that  some  of  the  fields  have  changed  from  nil  to  duration  values,  indicating  the 
time  to  the  next  internal  transition.  The  tables  show  they  are  in  the  #passive 
phase — that  is,  no  work  is  in  progress. 

Once  a  run  has  been  restarted,  either  of  the  Go  or  Step  buttons  may  be  used 
to  run  the  simulation.  The  Go  button  is  equivalent  to  repeated  pressing  of  the 
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Figure  2.2:  The  screen  for  a  simulation  run  after  restart. 
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Figure  2.3;  The  screen  for  a  simulation  run  after  one  step. 

Step  button.  The  Pause  button  may  be  used  to  interrupt  a  '‘Go”-ing  simulation 
run. 

Figure  2.3  shows  the  window  after  the  Step  button  has  been  pressed  once. 
On  this  first  step,  the  break  area  has  determined  that  all  three  operators  are  on 
duty  and  can  be  dispatched  to  the  various  tables  to  await  the  arrival  of  materials 
and  the  availability  of  workstations.  This  determination  is  reflected  in  the  fact 
that  the  operator  icons  are  outlined  in  white. 

Figure  2.4  shows  the  window  after  the  Step  button  has  been  pressed  again. 
Note  how  operator  Huey  (designated  by  the  “H”  on  the  icon)  has  been  dis¬ 
patched  from  the  break  area  to  Table  1,  the  equipment  at  which  his  next  work 
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Figure  2.4;  The  screen  for  a  simulation  run  after  two  sieps. 
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Figure  2.5:  The  screen  for  a  simulation  run  after  three  steps. 


assignment  occurs.  The  icon  shows  him  as  being  idle,  presumably  waiting  fur 
materials  to  arrive  since  the  equipment  itself  is  not  in  use.  [Note  that  no  time 
has  actually  passed  as  reflected  in  the  root  coordinator  view.]  The  drop  area  is 
ready  to  dispatch  the  three  rolls  of  fabric  at  the  end  of  this  ste^ 

Figure  2.5  shows  the  window  after  thu  Step  button  has  been  pre.ssed  again. 
The  operators  have  all  been  dispatched  to  the  equipment  at  which  they  can  next 
start  working  according  to  the  plan. 

Figure  2.6  shows  the  window  after  the  Step  button  has  been  pressed  four 
times.  At  this  point,  Huey  can  begin  work  on  the  ne.xt  work  assignment  since 
the  necessary  materials  have  arrived,  having  been  dispatched  from  the  drop 
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Figure  2.6:  The  screen  for  a  simulation  run  after  four  .steps 
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Figure  2.7:  The  screen  for  a  simulation  run  after  five  steps. 
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Figure  2.8:  The  screen  for  a  simulation  run  after  eight  steps. 


area.  Similarly,  Louie  can  begin  working  at  Table  2  with  the  arrival  of  materials 
(see  Figure  2.7). 

Figure  2.8  shows  the  window  after  the  simulation  run  has  been  stepped  until 
the  third  task  has  started.  Notice  how  Huey  is  now  working  at  a  different 
workstation  at  Table  1.  Five  minutes  of  simulated  time  have  passed,  the  time 
needed  for  Huey  to  complete  his  first  work  assignment.  Louie  has  completed 
his  work  eissignment,  but  the  simulation  has  not  yet  finished  processing  all  state 
changes  at  the  current  simulation  time.  Before  time  advances,  all  state  ch.aiiges 
for  Table  2  will  have  been  performed. 

Figure  2.9  shows  the  competed  simulation.  The  tickets  have  been  delivered 
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Figure  2.9:  The  screen  for  the  end  of  a  simulation  run. 
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the  system  with  a  minimum  amount  of  programming.  Adding  a  new  type  of 
equipment  or  other  resource  can  be  effected  by  using  inheritance.  Adding  new 
objects  amounts  to  creating  new  instances  of  existing  or  custom  classes. 

For  example,  consider  adding  a  new  kind  of  task — say,  one  to  both  spread 
and  cut.  The  basis  for  this  new  task  is  the  class  Task  which  encapsulates  the 
knowledge  of  what  it  means  to  be  “a  task.”  The  new  class,  SpreadAndCut.  is 
defined  as  a  subclass  of  Task  in  a  system  or  class  browser  (refer  to  the  doc¬ 
umentation  for  Smalltalk  for  details).  The  only  programming  required  is  the 
definition  of  the  method  that  computes  the  duration  of  time  required  to  com¬ 
plete  the  task  given  operator(s),  materials,  and  a  workstation. 

All  parts  of  the  system  can  be  customized  using  inheritance,  including  view.s 
and  the  default  graphics  used  for  various  resources. 
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Appendix  A 

Installation 


Installation  of  CflP  requires  the  availability  of  Objectworks\Smalltalk,  Version 
4.1  or  higher.  A  disk  containing  the  necessary  files  accompanies  this  manual. 

To  import  the  CflP  class  definitions  and  support  files  into  the  Smalltalk 
environment,  follow  these  steps: 

1.  If  necessary,  transfer  the  files  on  the  installation  diskette  to  a  disk  volume 
accessible  from  within  the  Smalltalk  environment. 

2.  Start  execution  of  the  Smalltalk  image  on  the  host  system. 

3.  Open  a  file  browser  by  selecting  file  list  from  the  UtiliUes  menu  in  the 
Launcher  window.  Deselect  the  “Auto  read”  feature,  type  ■‘*.ST”  in  the 
first  field  in  the  file  list  window,  then  hit  the  return  key.  A  list  of  the 
files  to  be  imported  appears  in  the  file  list  window.  Highlight  each  file  in 
turn  and  select  file  in  from  the  menu  obtained  by  holding  down  the  (first) 
mouse  button  when  the  cursor  is  positioned  over  the  bar  at  the  top  of  the 
list  of  files.  File-in  messages  will  appear  in  the  transcript  window.  Files 
may  be  processed  in  any  order,  but  the  messages  in  the  transcript  window 
will  depend  on  the  order  used. 

4.  Once  all  files  have  been  imported,  open  a  system  browser  by  selecting 
system  browser  from  the  Browsers  menu  in  the  Launcher  window.  The 
CflP  classes  will  appear  in  categories  whose  names  are  prefi.xed  with 
“CUP”  or  “DEVS”. 

Correct  installation  can  be  verified  by  running  the  test  in  the  file  simple .  tst. 
Open  a  file  editor  on  simple,  tst  by  selecting  file  editor  from  the  Utilities  menu 
in  the  Launcher  window.  Type  “simple. tst”  into  the  dialog  box  prompting  for 
the  file  name.  Double  click  at  either  the  start  or  end  of  the  text  in  the  window 
to  highlight  the  text  and  then  select  “do  it”  from  the  menu  obtained  by  holding 
down  the  (first)  mouse  button  while  the  cursor  is  positioned  over  the  bar  at  the 
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top  of  the  text  window.  A  simulation  run  window  will  appear.  Press  the  Restart 
button  with  the  mouse,  and  then  the  Go  button.  The  results  of  the  test  run  are 
written  to  the  system  transcript  window.  Close  the  simulation  window  when 
execution  completes. 
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Chapter  1 

Introduction 


This  document  describes  the  results  of  our  research  into  the  application  of 
object-oriented  technologies  to  the  development  of  a  simulation  of  cutting  room 
operations  in  an  apparel  plant.  We  gratefully  acknowledge  funding  of  this  re¬ 
search  by  the  Defense  Logistics  Agency  through  Clemson  Apparel  Research, 
Contract  Number  DLA900-87-D-0017,  D.O.  0019.  We  also  would  like  to  thank 
Jantzen  in  Seneca,  SC  for  their  interest  in  the  project  that  helped  us  get  support 
from  CAR,  and  Sundaresan  Jayaramen  at  Georgia  Institute  of  Technology  for 
help  in  understanding  cutting  room  operations  and  how  they  fit  into  the  larger 
manufacturing  process. 


1.1  Purpose 

The  purpose  of  this  research  has  been  to  investigate  whether  object-oriented 
technologies  can  be  useful  in  improving  the  efficiency  of  cutting  room  operations. 
The  cutting  room  is  responsible  for  construction  of  the  bundles  of  materials  that 
are  assembled  into  garments  in  the  sewing  room.  The  decision  as  to  the  order  in 
which  various  cutting  orders  are  processed  and  the  way  in  which  cutting  room 
resources — operators,  tables,  cutting  machines,  and  so  on — are  allocated  to  the 
cutting  orders  significantly  affects  the  efficiency  with  which  the  cutting  room 
operates.  When  this  project  started,  a  typical  apparel  plant  would  be  cutting 
orders  today  that  were  not  scheduled  for  sewing  for  another  two  or  three  weeks 
from  today.  Such  long  lead  times  tend  to  reduce  the  impact  of  problems  or 
inefficiencies  in  the  cutting  room  on  other  phases  of  production.  In  today’s 
competitive  environment,  practices  such  as  these  are  too  expensive.  Ideally, 
fabrics  would  arrive  in  the  warehouse,  almost  immediately  be  dispatched  to  the 
cutting  room  for  processing,  and  the  resulting  bundles  delivered  to  the  sewing 
room  just  when  they  are  scheduled  to  be  sewn. 

With  this  “just  in  time”  approach  to  manufacturing,  the  efficient  operation 
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of  the  cutting  room  is  more  critical  than  it  was  previously.  The  impact  of 
problems  in  the  cutting  room  is  even  more  significant  as  companies  such  as 
Jantzen  move  toward  centralized  cutting  facilities — that  is,  cutting  rooms  that 
cut  for  two  or  more  sewing  rooms,  some  of  which  might  be  quite  remote.  For 
example,  the  cutting  room  at  Jantzen  in  Seneca,  SC  cuts  for  the  sewing  room 
at  the  same  plant  as  well  as  plants  in  the  Caribbean. 

Cutting  room  management  is  currently  an  art.  Cutting  orders  must  be  as¬ 
signed  to  the  various  machines  and  operators  in  such  a  way  that  costs  are  held  to 
a  minimum  while  bundles  are  delivered  on  time.  For  example,  a  schedule  might 
call  for  cutting  black  wool  slacks,  white  cotton  shirts,  and  orange  sweatpants  on 
a  given  day.  If  the  cutting  room  contains  two  tables  with  automatic  spreaders 
and  two  operators  are  available,  then  the  manager  must  decide  which  orders 
will  be  cut  at  each  table  and  which  operator  will  be  assigned  to  each  cut.  If, 
for  example,  only  one  of  the  spreading  machines  can  handle  the  heavy  rolls  of 
wool,  then  some  of  the  decisions  don’t  have  to  be  made.  Still,  how  the  remain¬ 
ing  resources  are  assigned  to  the  work  significantly  affects  production  efficiency. 
The  problem  is  compounded  by  the  occasional  need  to  process  rush  orders  for 
cutting  pieces  for  sample  garments. 

Many  cutting  room  managers  just  have  a  “knack”  for  assigning  resources 
well.  He  knows  the  operators,  he  knows  the  equipment,  and  he  knows  from 
experience  about  how  long  each  cut  will  take.  Unfortunately,  if  a  cutting  room 
manager  leaves  a  plant,  the  problems  of  the  cutting  room  can  have  a  devastating 
effect  on  production  in  a  whole  plant.  In  fact,  this  research  was  first  suggested 
to  us  as  a  result  of  a  cutting  room  manager’s  leaving  and  throwing  a  whole 
plant  into  disarray  until  he  had  been  replaced  with  someone  who  could  get  the 
cutting  room  running  smoothly  again. 

Our  approach  in  addressing  this  problem  was  to  build  a  software  tool  to  sup¬ 
port  a  cutting  room  manager  in  making  decisions  with  respect  to  the  allocation 
of  cutting  room  resources  to  cut  orders.  Our  idea  was  to  build  a  software  system 
to  simulate  cutting  room  operations  for  a  given  set  of  cutting  orders  and  work 
assignments  based  on  those  orders.  A  cutting  room  manager  constructs  a  plan 
containing  work  assignments  for  the  operators.  A  work  assignment  comprises  a 
task  and  the  equipment  and  materials  to  be  used  in  performing  that  task.  Given 
such  a  plan,  the  system  simulates  the  operation  of  the  cutting  room,  determin¬ 
ing  when  each  assignment  is  completed  and  when  the  plan  is  completed.  The 
plan  can  be  revised  and  new  simulations  run  in  order  to  determine  the  effect  of 
these  changes  on  the  completion  times. 

We  proposed  to  base  the  system  on  object  technologies  for  two  reasons. 

1.  We  felt  that  the  system  would  be  most  useful  to  a  cutting  room  manager  if 
it  had  a  graphical  interface  such  that  an  animation  of  the  simulation  could 
be  displayed.  Animation  carries  more  impact  than  charts  and  tables.  Our 
goal  was  to  have  a  manager  be  able  to  watch  the  effects  of  a  plan  on  the 
cutting  room  as  operators  move  from  workstation  to  workstation,  as  rolls 
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of  fabric  are  processed  into  spreads,  as  spreads  are  cut  into  stacks,  and  as 
stacks  are  packaged  into  bundles. 

Most  modern  graphical  user  interfaces  (GUI)  are  based  on  object  lechisol- 
ogy.  Windows,  widgets,  icons,  and  geometric  shapes  are  represented  by 
objects. 

2.  Every  cutting  room  is  different.  The  number  and  capabilities  of  the  opera¬ 
tors,  the  number  and  types  of  equipment,  and  the  layout  of  the  equipment 
varies  from  cutting  room  to  cutting  room.  This  variety  would  generally 
mean  that  our  simulation  system  must  be  customized  for  each  cutting 
room.  We  saw  objects  as  a  good  way  of  making  the  customization  as 
easy  as  possible.  Since  objects  encapsulate  the  behavior  of  the  real-world 
entities  they  represent  in  software,  then  any  object  whose  behavior  cor¬ 
responded  to  what  the  simulation  expected  could  be  “plugged  into’  the 
system.  For  example,  the  addition  of  another  spreading  table  could  be 
effected  by  creating  an  object  to  represent  it,  putting  that  spreading  table 
object  into  the  cuttmg  room  object,  and  just  using  it  in  assignments  vs  ithin 
a  plan.  The  addition  of  ■»  new  type  of  cutting  machine  entails  describing 
the  behavior  of  the  machine,  r''nuiring  some  programming.  Hovs'ever.  in¬ 
heritance  from  the  general  class  of  cuttii;5  machines  or  even  from  a  specific 
type  of  cutting  machine  that  is  “almost  Pkc”  the  new  type  can  be  used  to 
define  most  of  the  behavior  of  the  machine  T rogramming  is  needed  only 
to  describe  any  differences.* 

1.2  Scope 

This  document  describes  the  design  and  implementation  of  CflP,  including 
information  about  DEVS,  the  simulation  methodology  used.  The  information 
in  this  document  is  complemented  by  information  in  the  CflP  User's  Manual 
and  in  the  actual  code  for  the  system.  Smalltaik-80  classes  are  not  documented 
here,  except  in  cases  where  changes  were  made  to  predefined  library  classes. 


1.3  Overview  of  the  Document 

The  remainder  of  this  document  is  structured  as  follows; 

•  Chapter  2  provides  information  about  object-oriented  programming  and 
DEVS,  the  methodology  that  we  chose  to  use  in  building  our  simulation. 

•  Chapter  3  presents  the  software  architecture  of  our  system.  The  descrip¬ 
tion  comprises  two  main  components: 

*We  could  hope  for  a  day  when  manufacturers  of  cutting  room  equipment  provide  class 
descriptions  of  each  of  the  products  that  they  sell  and  those  descriptions  could  be  used  directly 
by  the  simulation. 
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1.  The  implementation  of  DEVS 

2.  The  implementation  of  cutting  room  coiriponenis 

•  Appendix  A  provides  class  definitions  for  the  DEVS  component, 

•  Appendix  B  provides  class  definitions  for  the  cutting  room  compor!cmt.s 

A  separate  document,  CflP  User's  Manual,  details  the  user  iiiierface  and 
how  to  start  up  and  run  the  system. 


4 


Chapter  2 

Background 


We  present  a  brief  description  of  object-oriented  programming  and  of  the  DEVS 
methodology  on  which  the  discrete  event  simulation  aspect  of  our  design  is 
based. 


2.1  Object-Oriented  Programming 

In  this  section  we  will  provide  a  brief  description  of  object-oriented  program¬ 
ming.  Software  professionals  do  not  agree  as  to  exactly  what  constitutes  object- 
oriented  software,  but  we  adopt  Wegner’s[Weg87]  definition,  which  requires  that 
a  language  support  these  three  concepts  to  be  considered  object-oriented: 

•  Objects 

•  Classes 

•  Inheritance 

We  will  consider  a  software  system  to  be  object- onenied  if  it  is  designed 
and  implemented  using  these  three  concepts.  An  object-oriented  program  is  a 
software  system  whose  components  are  objects.  Computation  is  performed  via 
the  creation  of  new  objects  and  the  communications  between  them. 

2.1.1  Objects 

An  object  is  the  basic  component  of  the  object-oriented  paradigm.  Each  object 
is  characterized  by  its  own  set  of  attributes  and  by  a  set  of  operations  that  it  can 
perform.  The  values  of  attributes  may  change  as  a  result  of  the  application  of  the 
operations  and,  in  general,  only  through  the  operations.  Operations  are  referred 
to  as  methods  (or  member  fun  itions  in  C"'"'')  and  are  applied  via  the  process 
of  message  passing  (or  messaging).  A  message  sent  to  an  object  specifies  a 
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method  name  and  a  (possibly  empty)  list  of  arguments,  each  of  which  designates 
some  object.  A  message  received  by  an  object  causes  code  associated  with  the 
method  named  in  the  message  to  be  executed  with  its  formal  parameters  bound 
to  corresponding  values  in  the  argument  list.  The  processing  of  a  message  by 
the  receiving  object  might  result  in  a  state  change — that  is,  a  change  to  one 
or  more  of  the  receiving  object’s  attributes— and/or  the  sending  of  a  message 
to  itself  or  some  other  object.  It  is  useful  to  think  of  message  passing  as  being 
roughly  equivalent  to  function  calls  in  the  procedural  paradigm.  However,  the 
purpose  of  the  method  invoked  as  the  result  of  a  message  is  intended  to  modify 
the  internal  state  of  the  object  to  which  it  is  attached  rather  than  to  modify  its 
arguments  and  return  them.  An  object  may  even  send  itself  a  message.  Some 
languages  provide  special  terminology  to  allow  the  object  to  refer  to  itself — for 
example,  self  in  Smalltalk — or  let  the  object  be  the  default  if  another  object  is 
not  explicitly  referenced. 

As  an  illustration,  consider  polygons  drawn  on  a  computer  screen.  Each 
polygon  is  an  object  defined  by  an  ordered  collection  of  vertices.  The  order 
specifies  how  the  points  are  connected.  The  vertices  define  the  state  of  a  polygon 
object,  both  its  shape  and  its  location  on  the  screen.  Operations  on  a  polygon 
include  “draw”  (display  it  on  the  screen),  “move”  (erase  it  from  its  current 
location  and  redraw  it  at  some  specified  distance  in  the  z  and  y  directions), 
and  “contains?”  (a  check  whether  some  specified  point  is  inside  the  polygon). 
Figure  2.1(a)  shows  three  polygon  objects  on  a  computer  screen  and  the  points 
that  define  them.  Figure  2.1(b)  shows  how  these  polygons  are  represented  as 
objects. 

Note  that  in  describing  polygon  objects  we  have  used  other  objects — namely, 
a  screen  and  points.  A  screen  is  a  physical  object  that  for  our  needs  here 
comprises  an  arrangement  of  picture  elements  (or  pixels)  that  we  can  manipulate 
to  draw  shapes.  A  screen  object  provides  methods  to  turn  pixels  on  and  off,  to 
access  the  current  state  of  a  specified  pixel  (on  or  off  ),  and  to  draw  lines  between 
any  two  points,  where  the  screen  maps  points  to  pixels.  A  point  represents  a 
specific  pixel  according  to  some  x  and  y  coordinate  system.  A  point  object 
provides  methods  to  access  its  i  and  y  components  and  perhaps  to  compute  its 
distance  from  another  point. 

There  is  no  reason  why  objects  must  only  represent  physical  objects.  They 
may  be  instances  of  any  sort  of  conceptual  entity.  Processes  in  an  operating 
system,  the  level  of  illumination  in  a  room,  and  the  role  of  being  a  lawyer  in  a 
particular  trial  are  all  examples  of  objects. 

2.1.2  Classes 

A  class  is  a  set  of  objects  that  share  a  common  conceptual  basis.  The  definition 
of  a  class  includes  a  set  of  data  attributes  plus  the  set  of  allowable  operations 
on  that  data.  A  class  definition  can  be  viewed  eis  a  template  that  is  used  for 
the  production  of  objects.  All  objects  in  a  given  class  have  matching  attributes 
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Figure  2.1:  Polygon  objects. 
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Figure  2.2;  A  class  definition  for  quadrilaterals. 


and  operations.  Each  object  is  an  instance  of  some  class,  and  the  state  of  an 
object  is  contained  in  its  instance  variables. 

For  example,  the  two  quadrilaterals  in  Figure  2.1 — and  every  quadrilateral 
object — have  the  same  properties,  so  we  can  define  a  class  Quadrilateral  shown 
in  Figure  2.2  to  specify  these  properties.  Every  object  of  class  Quadrilateral  has 
the  same  set  of  instance  variables  and  methods  defined  by  the  class.  In  this 
sense,  the  class  Quadrilateral  provides  a  template  for  our  representation  of  all 
four-sided  polygon  objects,  specifying  both  the  variables  in  each  instance  of  a 
Quadrilateral  and  the  set  of  methods  that  can  be  sent  to  any  instance. 

An  instance  creation  operator  must  be  provided  in  order  to  produce  objects 
from  a  class  definition.  A  number  of  approaches  have  been  taken  by  object- 
oriented  programming  languages.  C"'"*',  for  example,  defines  an  explicit  new 
operation  that  creates  a  new  instance  of  a  specified  class,  incorporating  a  con¬ 
structor  concept  by  which  instances  are  initialized  implicitly  when  an  object 
of  the  class  is  created.  Smalltalk  uses  class  operators  to  create  instances.  The 
method  new  is  inherited  from  the  Object  class  and  serves  as  the  basis  for  creating 
instances  of  all  other  classes. 

Programming  languages  take  different  approaches  to  instance  destruction — 
that  is,  the  deletion  of  objects  when  they  are  no  longer  useful  so  memory  can 
be  made  available  for  other  objects.  C'*"*'  provides  a  delete  operator  that  can 
explicitly  free  up  the  space  used  by  an  object,  thereby  relying  on  the  programmer 
to  manage  objects  in  memory.  C*"*"  also  allows  each  class  to  define  a  destructor 
method  that  is  called  implicitly  when  an  object  is  destroyed.  Smalltalk,  on  the 
other  hand,  does  not  provide  a  mechanism  to  destroy  objects,  but  relies  instead 
on  garbage  collection. 

Most  languages  that  support  the  object-oriented  paradigm  provide  data  ab¬ 
straction  mechanisms.  The  mechanism  for  class  definition  provides  a  means  for 
designating  the  operations  that  users  of  the  class  will  be  able  to  access.  This 
set  of  operations  is  termed  the  class  interface.  The  remainder  of  the  class  defi¬ 
nition  provides  data  definitions  and  auxiliary  function  definitions  that  comprise 
the  class  implementation.  This  separation  isolates  the  users  of  the  class  from 
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the  effects  of  changes  to  the  internals  of  a  class. 

The  class  interface  is  the  set  of  operations  that  instances  of  the  class  can  be 
requested  to  perform.  The  simplified  public  interface  for  the  Quadrilateral  class. 
Figure  2.2,  shows  the  messages  to  which  instances  of  the  Quadrilateral  class 
can  respond.  Sending  the  message  draw  to  an  instance  of  class  Quadrilateral 
results  in  that  instance  executing  its  draw  operator.  The  draw  operator  would 
be  designed  to  draw  a  quadrilateral  having  shape  and  location  determined  by 
the  point  data  inside  the  instance. 

The  class  implementation  often  includes  instances  of  other  classes  that  pro¬ 
vide  services  the  new  class  requires.  In  the  quadrilateral  example,  the  four  points 
that  specify  a  quadrilateral  are  point  objects  defined  within  the  quadrilateral 
object.  These  point  objects  are  intended  to  be  inaccessible  from  other  objects. 
If  we  decide  that  it  is  important  for  other  objects  to  be  able  to  access  these 
points,  then  we  can  add  methods  to  the  class  interface  to  provide  this  access. 
For  example,  we  might  want  to  designate  one  point — perhaps  the  point  closest 
to  point  (0,0)  on  the  screen — as  a  reference  point.  We  would  define  a  method, 
say  referencePoint,  to  provide  that  value  rather  than  allowing  other  objects  to 
compute  it  from  the  values  of  pointj,  point2,  points,  and  point4.  A  class  imple¬ 
mentation  might  also  include  some  private  methods — for  use  in  implementing 
the  class,  but  not  intended  for  use  by  any  other  object.  For  example,  we  might 
want  a  private  method  that,  when  given  a  list  of  points,  determines  the  point 
that  is  closest  to  (0,0). 

A  class  is  similar  to — but  also  very  different  from — a  record  in  Pascal  or  a 
structure  in  C  in  the  sense  that  it  is  an  aggregation  of  data  values.  Classes 
normally  extend  the  usual  semantics  of  records  to  provide  varying  levels  of 
visibility — that  is,  <!ome  components  of  the  record  may  not  be  accessible  by  every 
component  that  has  visibility  to  the  record  type.  Classes  differ  from  records  in 
that  they  include  definitions  of  operators  with  the  same  status  as  the  data  values 
declared  within  the  class.  These  are  not  equivalent  to  function  pointers  that  are 
defined  independently  of  the  class  and  stored  in  the  class  instances. 

Virtually  all  object-oriented  languages  use  objects  as  the  representation  of 
the  instances  that  make  up  an  application.  Some  languages,  such  as  Smalltalk, 
also  implement  the  cleisses  themselves  as  objects.  Since  objects  are  the  ma- 
nipulatable  entities  in  an  object-oriented  application,  the  implication  is  that 
languages  that  implement  classes  m  objects  allow  the  manipulation  of  classes 
by  an  application.  This  capability  supports  the  flexibility  needed  in  many  ap¬ 
plication  areas  such  as  artificial  intelligence. 

2.1.3  Inheritance 

Inheritance  is  a  technique  for  using  existing  definitions  as  the  basis  for  new 
definitions.  The  definition  of  the  new  class  is  a  combination  of  the  data  and 
operation  declarations  from  the  existing  class(es)  and  any  declarations  added 
by  the  new  class.  The  new  class  reuses  the  existing  definitions  without  any  need 
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Figure  2.3:  An  exarnple  of  the  use  of  inheritance. 


to  modify  the  existing  classes.  It  is  less  expensive  to  develop  this  way  because 
a  portion  of  the  class  has  already  been  implemented  and  tested.  The  existing 
class  is  referred  to  as  the  parent  class,  the  base  class,  or  the  superclass.  The 
new  class  is  correspondingly  referred  to  as  the  child  class,  the  derived  class,  or 
the  subclass. 

Consider  the  Quadrilateral  class.  If  the  class  Polygon  shown  in  Figure  2.3(a) 
existed  when  class  Quadrilateral  was  defined,  then  the  definition  of  Quadrilateral 
could  have  looked  like  Figure  2.3(b).  The  italicized  items  in  Figure  2.3(b)  have 
been  defined  in  class  Polygon  and  added  to  the  definition  of  class  Quadrilateral 
through  the  inheritance  mechanism.  Presumably  these  elements  have  already 
been  tested  as  part  of  class  Polygon  and  may  not  need  to  be  retested  as  rigorously 
as  newly  written  code. 

Defining  a  new  class  using  inheritance  can  be  viewed  as  describing  a  new 
set  of  objects  that  is  a  subset  of  the  objects  described  by  the  existing  class. 
This  new  subset  can  be  thought  of  as  a  specialization  of  the  existing  class.  For 
example,  the  Quadrilateral  class  in  Figure  2.3  is  a  specialization  of  the  Polygon. 
A  quadrilateral  is  a  polygon  restricted  to  four  sides.  We  could  further  specialize 
a  quadrilateral  into  a  rectangle  which  is  a  quadrilateral  having  special  proper¬ 
ties.  The  interface  for  the  Quadrilateral  class  might  be  identical  to  that  of  the 
Polygon  class,  and  the  interface  for  a  Rectangle  might  be  the  same  as  that  of  the 
Quadrilateral. 

The  new  class  can  also  be  viewed  as  having  an  interface  that  is  an  expan¬ 
sion  of  the  interface  of  the  existing  class.  For  example,  deriving  a  four-wheel 
drive  vehicle  class  from  an  existing  vehicle  class  would  not  only  specialize  the 
definition  to  a  subset  of  vehicles,  but  probably  also  introduce  new  capabilities 
in  the  new  class  interface.  Continuing  with  our  example,  we  might  wish  to  add 
more  operations  for  a  rectangle — for  example,  a  method  that  would  answer  the 
largest  ellipse  that  can  be  enscribed  in  that  instance. 
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Figure  2.4:  An  inheritance  hierarchy  for  some  polygon  classes. 

How  much  of  the  existing  definition  is  available  to  be  added  to  the  new  defini¬ 
tion  varies  from  one  language  to  another.  Many  languages  give  the  implementor 
control  over  which  attributes  are  actually  inherited  and  how  they  are  inherited. 
Typically,  the  system  developer  may  choose  to  either  inherit  only  the  interface 
and  not  the  representation  or  to  inherit  both  the  interface  and  the  representa¬ 
tion.  In  our  approach  to  object-oriented  design,  we  inherit  all  the  attributes  of 
the  existing  class  in  the  new  class  definition,  despite  what  facilities  our  imple¬ 
mentation  language  might  provide  to  hide  inherited  attributes.  Our  approach 
leads  to  the  development  of  inheritance  structures  that  are  conceptually  rational 
and  understandable. 

2.1.4  Polymorphism  and  Dynamic  Binding 

Objects,  classes,  and  inheritance  characterize  the  object-oriented  paradigm,  but 
other  techniques  are  used  in  conjunction  with  them  to  provide  additional  power. 
Two  of  these  are  polymorphism  and  dynamic  binding. 

A  language  supports  polymorphism  if  the  same  name  or  symbol  can  be  used 
in  different  contexts.  In  an  object-oriented  programming  language,  more  than 
one  class  may  use  the  same  method  names,  and  hence  the  various  instances  of 
these  classes  can  respond  to  the  same  messages,  though  each  in  its  own  way.  The 
determination  of  which  method  to  dispatch  when  a  message  is  received  by  an 
object  is  determined  through  dynamic  binding — that  is,  the  method  dispatched 
is  determined  by  the  class  of  the  receiving  object  at  run  time.  Consider,  for  ex¬ 
ample,  the  class  hierarchy  shown  in  Figure  2.4.  By  polymorphism,  any  instance 
of  these  classes  can  reply  to  a  message  contains?(p),  but  the  way  in  which  the 
answer  is  computed  depends  on  the  kind  of  polygon.  If  the  message  is  sent  to 
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P,  then  the  method  dispatched  to  compute  the  answer  depends  on  whether  P  is 
a  triangle,  a  quadrilateral,  or  a  rectangle.  In  this  way,  the  action  taken  depends 
on  the  class  of  P  at  run  time. 

2.1.5  Benefits 

We  briefly  examine  some  of  the  reasons  for  using  object-oriented  design  and 
implementation  techniques:  Object-oriented  programming 

•  Promoies  reusability.  Object-oriented  techniques  yield  structures  that  are 
more  readily  reused  than  other  design  techniques.  Reuse  comes  in  many 
forms: 

1.  There  is  reuse  by  using  an  instance.  For  example,  an  application 
might  use  many  instances  of  class  Quadrilateral. 

2.  There  is  reuse  by  using  an  instance  in  a  definition.  For  example,  the 
Quadrilateral  uses  instances  of  class  Point. 

3.  There  is  reuse  by  evolution.  For  example,  class  Quadrilateral  is  used 
to  define  class  Rectangle. 

The  support  for  data  abstraction  in  object-oriented  methods  promotes 
these  types  of  reuse.  Designers  view  object-oriented  techniques  from  dif¬ 
ferent  perspectives.  Those  currently  using  languages  such  as  C  will  see  the 
additional  potential  for  reuse  provided  by  classes.  Those  using  languages 
such  as  Ada  or  Modula-2  will  see  packages  and  modules  as  providing  the 
first  two  types  of  reuse.  What  they  will  not  have  seen  is  the  third  type  of 
reuse. 

•  Facilitates  maintenance.  The  information-hiding  supported  by  most  object- 
oriented  programming  languages  facilitates  maintenance.  The  interface  of 
a  class  defines  the  set  of  operations  on  the  data  of  an  instance  of  that  class. 
If  a  change  is  made  to  the  representation  of  data  defined  in  the  class,  then 
those  operations  defined  in  the  class  that  interact  with  the  changed  data 
need  to  be  modified.  There  is  no  need  for  users  to  modify  their  references 
to  instances  of  the  class  unless  the  signature  of  one  of  the  operations  has 
been  changed.  The  impact  of  this  and  many  other  maintenance  activities 
is  localized. 

For  example,  consider  an  implementation  of  the  class  Rectangle  in  which 
we  wish  to  use  two  points  to  define  it  instead  of  four  points.  [Note  that  if 
we  require  a  rectangle  to  be  aligned  with  the  x  and  y  axes,  then  we  can 
define  it  in  terms  of  its  upper-left  vertex  and  its  lower-right  vertex.  Many 
microcomputer  systems  provide  facilities  to  draw  rectangles  in  terms  of 
these  two  points.]  The  methods  draw,  move,  contains?,  and  referencePoint 
would  have  to  be  reimplemented  to  determine  the  other  two  points  if  they 
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are  needed.  These  changes  would  be  localized  to  the  code  of  the  methods 
of  the  Rectangle  class. 

•  Exploits  commonality.  Object-oriented  techniques  exploit  commonality 
in  two  ways.  First,  there  is  commonality  across  applications.  Software 
development  firms  tend  to  develop  applications  that  address  a  common 
domain  such  as  communications  or  graphics.  By  developing  units  that 
are  easily  reused,  object-oriented  design  exploits  the  commonality  within 
a  company’s  applications.  Second,  there  is  commonality  across  system 
components.  For  example,  a  graphics  system  defines  numerous  shapes 
such  as  lines,  triangles,  circles,  and  rectangles.  These  components  are 
different  shapes,  but  they  have  many  common  attributes.  Object-oriented 
design  develops  a  structure  that  factors  out  these  common  elements  into 
a  class,  which  can  then  be  the  basis  for  defining  each  of  the  individual 
shape  classes. 

•  Reduces  complexity.  This  is  where  the  advertisement  starts  because  we 
have  little  more  than  anecdotal  evidence  to  support  this  claim.  A  recent 
paper  by  Rosson  and  Gold[RG89]  does  provide  some  evidence  in  support  of 
the  claim.  Existing  procedural  techniques  require  that  the  designer  have 
a  solution  in  mind  before  beginning  the  design  process  This  requires 
the  designer  to  be  an  expert  problem  solver  because  the  design  technique 
only  supports  the  computerization  of  a  solution  rather  than  the  problem¬ 
solving  process.  This  further  implies  that  the  designer  cannot  begin  the 
system  design  until  a  complete  problem  solution  is  known.  With  today’s 
complex  systems,  this  is  often  a  severe  limitation. 

Object-oriented  techniques  begin  the  development  process  in  the  problem 
domain  rather  than  in  the  solution  domain.  This  relieves  the  designer 
from  developing  a  complete  solution  before  beginning  any  design  work. 
Thus,  the  designer  is  able  to  handle  more  complex  problems  because  of 
the  support  provided  by  the  design  techniques. 

We  have  used  these  techniques  because  we  wanted  an  effective  solution.  We 
proposed  to  use  object-oriented  techniques  for  the  design  and  implementation 
of  CflP  for  a  number  of  reasons: 

•  The  use  of  objects  in  design  leads  to  an  architecture  that  is  characterized 
by  discrete  structures  that  communicate  with  each  other.  The  encapsu¬ 
lation  of  functionality  means  that  otherwise  lengthy  and  complex  flows 
of  control  are  decomposed  into  shorter,  simpler  segments  hidden  within 
the  individual  objects.  Consider  the  simulation  component  of  CflP  .  The 
functionality  needed  to  simulate  the  passage  of  simulated  time,  to  post 
the  time  of  next  event  for  a  given  object,  and  even  to  display  an  object 
must  be  provided  for  each  simulation  object.  In  different  scenarios,  users 
may  have  the  power  to  create  an  almost  unlimited  number  of  cutting  room 
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resources  to  use  in  a  simulation  run.  Having  each  instance  of  a  resource 
contain  the  functionality  that  it  needs  results  in  an  architecture  that  dis¬ 
tributes  responsibility.  Such  a  system  easily  handles  multiple  occurrences 
of  complex  resource  entities. 

•  The  use  of  inheritance  to  evolve  new  definitions  from  existing  ones  sup¬ 
ports  the  solution  of  complex  problems.  Areas  in  which  solutions  evolve 
over  time  rather  than  being  obvious  at  the  outset  require  many  changes  as 
an  application  is  developed.  Developing  subclasses  from  existing  classes 
allows  the  designer  to  modify  the  behavior  of  classes  incrementally  as 
new  information  about  a  solution  becomes  available.  These  changes  can 
be  made  without  disturbing  existing  software  components,  which  depend 
on  the  classes  that  are  to  be  modified.  We  want  to  be  able  to  add  new 
equipment  to  a  cutting  room  as  well  as  to  be  able  to  add  new  kinds  of 
equipment. 

•  The  encapsulation  of  representation  characteristic  of  objects  supports  the 
prototyping  of  systems.  Once  the  module  interfaces  are  developed,  the 
underlying  representations  of  classes  can  be  modified  without  impacting 
the  modules  that  use  the  services  of  the  changing  module.  Quickly  de¬ 
veloping  the  behavior  of  a  simulation  object  can  be  followed  by  detailed 
implementation  that  provides  specialized  responses.  Strictly  speaking,  this 
is  a  characteristic  of  data  abstraction  that  is  an  integral  part  of  object- 
orientation.  Our  goal  has  been  to  develop  a  prototype  that  can  be  refined 
later  for  a  specific  installation.  We  have  been  less  concerned  about  finding 
actual  values  for  things  such  as  operator  efficiency  and  spread  rates  for 
equipment,  and  more  concerned  about  identifying  how  all  the  objects  need 
to  interface  in  order  to  produce  a  meaningful  simulation  run. 

2.2  DEVS 

In  this  section  we  describe  how  DEVS  works.  [For  a  more  formal  treatment  and 
further  details,  see  Zeigler’s  book.] 

The  DEVS  methodology  is  based  on  the  definition  of  models  and  on  the 
interconnection  of  these  models  to  construct  larger  models  which  may,  in  turn, 
be  connected  to  other  models.  This  layered  construction  provides  a  hierarchy 
of  models.  Each  model  is  modular  in  the  sense  that  it  can  be  used  in  a  variety 
of  simulations. 

Two  main  kinds  of  entities  exist  in  DEVS-Scheme;  models  and  processors. 
Models  contain  information  and  operations  about  the  domain  of  interest.  Pro¬ 
cessors  carry  out  the  simulation  of  DEVS  models. 

In  this  section  we  describe  models,  processors,  and  simulation  in  DEVS. 
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2,2.1  Models 


Zeigler  describes  a  DEVS  model  as  an  object  containing  the  following  informa¬ 
tion  [Zei90,  pp.  48-49]; 

•  a  set  of  input  ports  through  which  external  events  are  received 

•  a  set  of  output  ports  through  which  external  events  are  sent 

•  the  set  of  state  variables  and  parameters:  two  state  variables  are  usually 
present — phase  and  sigma  (in  the  absence  of  external  events  the  system 
stays  in  the  current  phase  for  the  time  given  by  sigma) 

•  the  time  advance  function  which  controls  the  timing  of  internal  transitions — 
when  the  sigma  state  variable  is  present,  this  function  just  returns  the 
value  of  sigma. 

•  the  internal  transition  function  which  specifies  to  which  next  state  the 
system  will  transit  after  the  time  given  by  the  time  advance  function  has 
elapsed 

•  the  external  transition  function  which  specifies  how  the  system  changes 
state  when  an  input  is  received — the  effect  is  to  place  the  system  iti  a  new 
phase  and  sigma  thus  scheduling  it  for  a  next  internal  transition;  tlie  next 
state  is  computed  on  the  basis  of  the  present  state,  the  input  po;;  and 
value  of  the  external  event,  and  the  time  that  has  elapsed  in  the  cm  rent 
state. 

•  the  output  function  which  generates  an  external  output  just  befon-  an 
internal  transition  takes  place. 

DEVS  models  comprise  two  categories;  atomic  models  and  coupled  model. 
Atomic  Models 

Atomic  models  are  those  models  at  the  lowest  level  of  the  hierarchy.  The  behav¬ 
ior  of  such  a  model  is  determined  by  the  input  even  types  it  recognizes,  its  state 
variables  and  parameters,  its  time  advance  function,  its  internal  transition  func¬ 
tion,  its  external  transition  function,  and  its  output  function.  We  characterize 
an  atomic  model  by  means  of  a  simple  example. 

Figure  2.5  shows  a  graphical  representation  of  a  simple  processor.  The  pro¬ 
cessor  being  modeled  is  provided  with  jobs,  each  requiring  a  fixed  amount  of 
processing  time.  This  processor  does  not  queue  up  jobs  as  they  arrive.  If  a  job 
arrives  while  the  processor  is  busy  with  a  job,  then  the  arriving  job  is  ignored. 

The  model  behaves  in  accordance  with  the  description  provided  in  the  right 
part  of  the  figure.  When  the  model  receives  an  input  z  on  port  in  and  the 
processor  is  idle  (state  passive),  then  the  processor  starts  to  work  on  the  job 
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State  variables: 

sigma  =  oo 

phase  =  passive 

jobID  =  None 

Parameters: 

processingTime  =  5 

External  transition  function: 
if  phase  is  passive  then 

jobID  «—  input  job  ID 
hold  in  phase  busy  for  processingTime 
else  -  -phase  is  busy 

continue 

Internal  transition  function: 
case  phase  is 

busy:  passive 

passive:  (Does  not  arise) 

Output  function: 
send  joblD  to  port  out 

Figure  2.5:  A  DEVS  model  for  a  simple  processor. 
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whose  ID  is  specified  in  z.  The  processing  time  for  each  job  is  fixed  at  five  time 
units  (parameter  processtngTime).  After  processing  time  has  passed,  the  identi¬ 
fication  of  the  completed  job  is  emitted  on  output  port  out  as  determined  by  the 
output  function.  If  a  job  arrives  on  the  input  port  while  the  processor  is  already 
busy  (as  signified  by  phase  busy),  the  arriving  job  is  ignored  as  determined  by 
the  external  transition  function’s  handling  of  an  input  when  the  processor  is  in 
the  busy  phase. 

An  atomic  model  can  have  any  number  of  input  and  output  ports.  The 
external  input  function  must  specify  an  action  for  an  arrival  on  each  of  the 
input  ports.  Usually,  the  processing  associated  with  an  arrival  on  aiiy  given 
port  is  determined  by  the  current  state  of  the  model — as  determined  by  phast 
and  possibly  other  state  variables — and/or  by  the  object  arriving  on  the  port. 

Wfith  respect  to  the  management  of  state  and  time,  four  actions  are  com¬ 
monly  taken: 

1.  hold-in  phase  for  duration.  The  model  stays  in  the  phase  indicated  for 
the  duration  of  time  indicated.  Thus,  the  next  internal  transition  occurs 
at  the  current  time  plus  the  duration  indicated.  However,  the  arrival  of 
an  external  input  might  preempt  that  next  internal  transition. 

2.  passivate  in  phase.  The  model  enters  the  phase  indicated  for  an  infinite 
amount  of  time,  equivalent  to  hold-tn  phase  for  co.  Thus,  no  next  internal 
transition  is  scheduled  to  occur  and  the  model  will  react  only  to  external 
inputs. 

3.  passivate.  The  model  enters  a  passive  phase  for  an  infinite  amount  of  time, 
equivalent  to  passivate  in  passive. 

4.  continue.  The  model  continues  in  the  same  phase,  reducing  the  amount 
of  time  to  the  next  internal  transition  by  the  amount  of  (simulated)  time 
passed  in  this  state  so  far. 

It  is  important  to  realize  that  an  atomic  model  has  no  conception  of  a  global 
simulation  time.  Time  relates  only  to  the  state  transitions  that  a  model  must 
undergo.  In  the  simple  processor  example,  the  model  is  either  busy  or  passive 
and  oblivious  to  the  current  simulation  time.  The  only  times  of  significance  are 
durations — the  elapsed  times  at  which  state  transitions  occur. 

Coupled  Models 

A  coupled  model  comprises  a  set  of  components — each  an  atomic  or  coupled 
model —  with  specified  interconnections  A  coupled  model  contains  the  following 
information: 

•  the  set  of  component  models 

•  the  set  of  input  ports  through  which  external  events  are  received 
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Figure  2.6:  A  simple  coupled  model  for  a  queuing  proce.ssor  The  queue  ..s  aseu 
to  hold  jobs  waiting  for  the  simple  processor 


•  the  set  of  output  ports  through  which  external  event.s  -are  sent 

•  for  each  component,  its  tnfluencees—the  other  components  of  the  tnodei 
that  affect  it 

•  the  coupling  specification: 

-  the  external  input  coupling  that  specifies  how  input  ports  ;f  the 
coupled  model  are  connected  to  input  ports  of  the  •-omponent  models 

-  the  external  output  coupling  that  specifies  how  luipiu  port.s  d'  tiie 
component  models  are  connected  to  the  output  ports  of  tiie  i.;ou|>ieu 
model 

-  the  internal  coupling  that  specifies  how  the  output  ports  if  -ompo- 
nents  are  connected  to  the  input  ports  of  components 

Note  that  an  output  port  of  a  component  model  can  be  tonnected 
any  number  of  the  input  ports  of  component  models  as  well  as  to  .any 
number  of  output  ports  of  the  coupled  model.  Similarly,  an  input  port 
of  the  coupled  model  can  be  connected  to  any  number  of  input  ports  of 
component  models. 

•  the  select  function  that  specifies  the  order  in  which  two  or  n>ore  compo 
nents  that  are  ready  for  a  state  transition  at  the  same  time  will  undergo 
the  transition. 

Consider  the  coupled  model  shown  in  figure  2.6.  This  model  is  for  what  we  ii 
call  a  "queuing  processor"  because  it  queues  jobs  until  they  ran  be  processed 
It  comprises  two  models:  one  simple  processor  model  and  one  queue  model. 
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queuing  processor  has  one  input  port — in—  and  one  output  port — Input 
jobs  are  routed  to  the  queue  component  model  which  buffers  jobs  arriving  on  its 
in  port  and  sends  jobs  one  at  a  time  to  the  processor  in  response  to  an  arrival 
of  anything  on  its  send  port.  The  output  of  the  processor  is  routed  both  to  the 
output  of  the  queuing  processor  and  to  the  send  input  port  of  the  queue. 

Note  that  the  queue  model  could  be  either  atomic  or  coupled.  The  behavior 
of  either  type  of  model  is  indistinguishable,  illustrating  the  modularity  of  DK\'S 

2.2.2  Processors 

Within  a  simulation  run,  each  DEVS  model  is  controlled  by  a  processor  that 
monitors  the  passage  of  simulated  time  and  activates  functions  in  the  model  as 
appropriate.  There  is  aone-loone  mapping  of  processors  to  models.  The  model 
attached  to  a  processor  is  referred  to  as  the  processor’s  devsComponenl.  Each 
atomic  model  is  controlled  by  a  simulator.  Each  coupled  model  is  controlled 
by  a  coordinator.  A  special  processor,  a  root  coordinator,  manages  the  overall 
simulation  and  is  linked  to  the  coordinator  of  the  outermost  coupled  model 
Processors  are  linked  in  a  tree  that  reflects  model  hierarchy.  Leaf  nodes  are 
simulators  while  internal  nodes  are  coordinators  except  for  at  the  root.  The 
configuration  for  the  processor  example  is  shown  in  figure  2.7.  Processor  objects 
are  shown  as  circles,  models  as  rectangles. 

Processors  send  and  receive  four  kinds  of  messages  to  effect  simulation.  A 
processor  takes  action  on  its  attached  model  based  on  the  type  and  content  of 
the  messages  it  receives.  Simulation  begins  when  the  root  coordinator  sends  the 
first  message  to  indicate  the  start  of  simulated  time.  The  message  is  routed  by 
processors  through  the  hierarchy  to  a  model  with  an  appropriate  state  change. 
(Models  are  prioritized  so  that  if  more  than  one  has  a  state  change  imminent. 
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then  the  next  one  to  change  is  selecteJ  deterministically.)  A  state  change  can 
result  in  outputs  that  affect  other  models.  Messages  are  routed  by  processors 
as  appropriate  based  on  output  and  input  port  connecti:)ns  between  models. 
Eventually,  once  all  state  changes  at  the  current  time  have  settled  out,  the  root 
coordinator  receives  a  message  indicating  that  simulation  time  can  advance  and 
a  cycle  of  messages  is  begun  anew.  Simulation  terminates  after  some  preset 
duration  or  when  no  more  transitions  are  scheduled  for  any  of  the  models  in  the 
simulation. 

The  four  message  types  used  in  DEVS  are; 

♦  — indicates  that  the  next  internal  event  is  to  be  carried  out  within  the  scope 

of  the  processor  receiving  the  message. 

I  — signifies  the  arrival  of  an  external  input  to  a  processor's  model  and  bears 
the  global  model  time  of  that  event.  The  input  value  and  port  of  arrival 
are  indicated  in  the  message  content. 

y  — carries  the  output  of  a  model  in  its  content  and  the  global  model  lime  at 
which  output  occurred. 

done  — indicates  that  a  state  transition  has  been  carried  out  and  bears  the 
global  time  of  the  next  event. 

A  message  comprises  three  main  components: 

source  — designating  the  originator  of  the  message. 

time  — a  simulation  time  stamp  or  a  duration,  depending  on  the  use. 

content  — comprising  a  port  designation  and  a  valne.  determined  by  the  model 
output  function.  This  component  is  not  meaningful  for  done  and  •  mes¬ 
sages. 

Simulators 

Simulators  handle  atomic  models  in  a  simulation.  A  simulator  S:M  for  atomic 
model  M  tracks  the  global  time  at  which  the  last  event  occurred  in  M  and  the 
global  time  at  which  the  next  event  will  occur,  based  on  the  duration  of  time 
provided  by  M’s  time  advance  function. 

A  simulator  receives  *  and  z  messages  and  sends  y  and  done  messages  in 
reply.  A  simulator  S.M  having  devsComponent  M  acts  cis  follows  in  response  to 
r  and  *  messages: 

•  Upon  receipt  of  an  r  message,  S:M  activates  the  external  transition  func¬ 
tion  of  M  and  then  respond  by  sending  a  done  message  to  its  parent  proces¬ 
sor.  The  done  message  indicates  that  the  transition  has  been  performed 
and  carries  with  it  the  simulation  time  of  M’s  next  internal  transition. 
This  time  is  computed  by  adding  the  value  of  M’s  lime  advance  function 
to  the  time  carried  in  the  x  message. 
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•  Upon  receipt  of  a  ♦  message,  S;M  activates  M’s  internal  transition  func¬ 
tion  and  responds  by  sending  a  y  message  to  its  parent,  followed  by  a 
done  message.  The  y  message  content  contains  the  output  port  and  value 
computed  by  M’s  output  function.  The  done  message  indicates  that  the 
transition  has  been  carried  out  and  indicates  the  simulation  time  of  M’s 
next  internal  transition. 

Coordinators 

Coordinators  handle  coupled  models  in  a  simulation.  A  coordinator  C:M  for 
coupled  model  M  tracks  the  global  time  at  which  the  last  event  occurred  in  M 
and  the  global  time  at  which  the  next  event  will  occur.  A  coordinator  also  main¬ 
tains  a  list  of  the  processors  for  the  component  models  of  its  devsComponent, 
sorted  according  to  increasing  time  until  the  next  transition.  The  processor  at 
the  head  of  this  list  is  the  processor’s  imminent  child.  If  two  or  more  models 
have  matching  times,  then  a  selection  function  is  used  to  determine  the  order. 
Ordinarily  this  function  consults  a  prioritized  list  of  the  models. 

A  simulator  receives  and  sends  all  four  kinds  of  messages: 

•  Upon  receipt  of  an  x  message,  C;M  transmits  this  message  to  each  of  M’s 
component  models  that  have  input  ports  connected  to  the  port  indicated 
in  the  message. 

•  Upon  receipt  of  a  ♦  message,  C:M  transmits  a  *  message  to  its  imminent 
child. 

•  When  a  coordinator  receives  a  y  message  from  its  imminent  child,  it  checks 
the  coupling  in  the  model  to  see  whether  the  output  port  in  the  message 
is  connected  to  an  output  port  of  the  coupled  model.  If  so,  the  message 
is  transmitted  to  its  parent.  Next,  if  the  output  port  indicated  in  the 
message  is  connected  to  an  input  port  of  any  other  models  within  the 
coupled  model,  then  the  output  value  is  transmitted  to  each  child  in  an  z 
message  directed  to  the  appropriate  port. 

•  After  a  coordinator  receives  a  done  for  each  of  the  x  messages  it  has  sent 
to  children  and  the  y  messages  it  has  sent  to  parents,  then  it  determines 
a  new  imminent  child  from  among  its  children  and  sends  the  time  for  the 
imminent  child’s  next  event  in  a  done  message  to  its  parent. 

Root  Coordinators 

A  root  coordinator  controls  a  simulation  run.  Unlike  the  other  two  kinds  of  pro¬ 
cessors,  a  root  coordinator  has  no  model  attached,  but  a  coordinator  attached 
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Figure  2.8:  A  simple  hierarchical  model  of  a  job  generacor,  transducer,  and 
simple  processor. 


instead.^  A  root  coordinator  maintains  the  current  global  simulation  time  and 
starts  the  simulation  by  sending  a  ♦  message  containing  the  current  simulation 
time  to  the  attached  coordinator.  When  the  coordinator  responds  with  a  done 
message  indicating  the  time  of  the  next  event,  the  root  coordinator  updates  the 
simulation  clock  and  starts  the  next  cycle  with  another  ♦  message.  The  coordi¬ 
nator  might  send  a  y  message  to  a  root  coordinator.  This  message  contains  the 
output  of  the  model.  A  root  coordinator  just  ignores  such  messages  by  default. 


2.2.3  Simulation 

We  illustrate  the  operation  of  DEVS  on  a  simple  model  taken  from  [ZeiOO]  and 
shown  in  Figure  2.8.  At  the  top  level,  this  model  comprises  a  processor  mode! 

'Zeigler  describes  only  a  cornection  to  a  coordinator.  These  seems  to  be  no  reason  why 
a  simulator  ceinnot  be  attached,  though  perhaps  atomic  models  are  just  not  interesting  by 
themselves. 
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ATOMIC  MODEL;  GENR 


state  vanabies:  sigma  =  infinity 
phase  =  active 

parameters:  interarrival-time  =  10 

external  transition  function: 
case  input-port 
stop;  passive 
else;  error 

internal  transition  function: 
case  phase 

active:  hold-in  active  interarrival-time 
peissive:  (does  not  arise) 

output  function: 
case  phase 

active;  send  a  random  job  name  to  port  out 
passive;  (does  not  arise) 


Figure  2.9;  Pseudo-code  for  a  job  generator. 


and  an  experimental  frame  model.  The  latter  is  a  digraph  model  comprising 
two  other  models,  a  job  generator  and  a  transducer.  The  job  generator  creates 
a  job  every  ten  seconds  until  signaled  to  stop.  The  transducer  collects  statistics 
about  jobs — average  turnaround  time  and  throughput — by  monitoring  the  jobs 
generated  and  processed.  The  transducer  model  includes  a  clock  among  its  state 
variables  to  track  global  simulation  time.  Descriptions  of  the  models  are  given 
in  Figures  2.9  through  2.12.  For  a  more  detailed  description  these  models,  .see 
Chapter  5  of  [Zei90]. 

The  sequence  of  messages  to  effect  simulation  is  given  below.  This  sequence 
is  quite  lengthy  even  though  a  significant  part  of  it  has  been  deleted.  We  present 
this  level  of  detail  in  order  to  describe  the  operation  of  DEVS.  This  level  is  not 
provided  in  [Zei90],  and  we  worked  for  a  long  time  to  collect  the  information 
necessary  to  determine  how  messages  are  generated  and  processed.  While  the 
sequence  below  is  difficult  to  follow  because  of  its  length,  it  does  serve  as  a 
reference  for  determining  the  correct  operation  of  a  simulation. 

The  levels  of  indentation  in  the  sequence  roughly  match  the  levels  in  the 
hierarchy.  One  can  easily  see  how  messages  propagate  down  the  levels,  back  up, 
down  again,  and  finally  back  up.  Actions  shown  in  italics  correspond  to  actions 
on  an  atomic  model  attached  to  the  simulator.^ 

^This  sequence  »sui  generated  by  C/IP  during  a  run.  We  have  included  a  provision  for 
producing  LaTeX  commands  which  can  be  formatted  to  decipher  the  operation  of  the  system 
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ATOMIC  MODEL;  TRANSD 


state  variables:  sigma  =  observation-interval 
phase  =  active 
arrived-iist  =  () 
solved-list  =  () 
clock  =  0 
total- ta  =  () 

parameters:  interarrival-time  =  10 

external  transition  function: 

advance  local  clock  to  agree  with  global  clock; 
case  input-port 

ariv:  append  job  to  arrived-list 
solved:  find  job  arrival  time; 

total-ta  =  clock  -  arrival-time; 
put  the  job  to  solved-list 

continue 

internal  transition  function: 
case  phase 

active:  passive  -  -  end  of  observation  interval 
output  function; 
case  phase 

active:  average-turnaround-time  = 

total-ta  /  solved-job-number; 
thruput  =  solved-job-number  /  clock 
else:  no  output 


Figure  2.10:  Pseudo-code  for  a  transducer. 
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DIGRAPH  MODEL:  EF 


composition  tree:  root:  EF 

leaves:  GENR,  TRANSD 

external  input  coupling:  external  output  coupling: 


EF.in  —  TRANSD. solved 

GENR. out  — '  EF.out 

TRANSD. out  — •  EF. result 

influence  digraph; 

internal  coupling; 

GENR  —  TRANSD 

GENR.out  — ►  TRANSD. ariv 

TRANSD  —  GENR 

TRANSD. out  — *  GENR.stop 

Figure  2.11:  Composition  tree  and  influence  digraph  for  an  experimental  frame 


DIGRAPH  MODEL:  EF-P 

composition  tree:  root:  EF-P 
leaves:  EF,  P 

external  input  coupling 
none 

influence  digraph: 

P  —  EF 
EF  —  P 

priority  list:  (  P  EF  ) 

Figure  2.12:  Composition  tree  and  influence  digraph  for  model/frame  pair. 


external  output  coupling: 

EF. result  — ►  EF-P.out 
internal  coupling: 

P.out  — +  EF.in 
EF.out  — ♦  Pin 
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RC  EF-P  S:P  EF  S:GENR  S:TRANSD 


restartAt;  Dec  1,  00:00 
restarting  P  at:  Dec  1,  00:00 


restartAt:  Dec  1,  00:00 

send: 

Infinity 

recv:  Infinity 

)ec  1,  00:00 

restarting  EF  at:  I 

restartAt:  Dec  1,  00:00 
restarting  GENR  at:  Dec  1,  00:00 
restartAt:  Dec  1,  00:00 


send: 

Dec  1,  00:00 

recv: 

Dec  1,  00:00 

restarting  TRANSD  at:  Dec  1,  00:00 

restartAt:  Dec  1,  00:00 
send:  ^■’"'1  Dec  1,  01:40 


recv: 

send: 


Done 


recv: 

send: 

Dec  1,  01:40 

'  Dec  1,  00:00 

Dec  1,  00:00 

'  Dec  1,  00:00 

Time;  Dec  1,  00:00 

send: 


Dec  1,  00:00 

recv:  'j 
send:  ’ 

Dec  1,  00:00 

Dec  1,  00:00 

recv:  * 

Dec  1,  00:00 

send;  ' 

'  Dec  1,  00:00 

1 _ 

recv:  * 

Dec  1,  00:00 

output?()  —* 

’Job  0’ 

send:  »  Dec  I,  00:00:  ’Job  0’ 


at  the  lowest  level.  Obviously,  the  amount  of  messaging  that  occurs  in  a  simulation  run  is  very 
large  and  being  able  to  format  that  output  meaningfully  is  of  considerable  help  in  debugging. 
See  Section  3.4  for  details  on  how  to  produce  this  output. 
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RC  EF-P  S:P  EF  S:GENR  S:TRANSD 


recv:  ^  Dec  1,  00:00:  ’Job  0’ 
send;  '’I  Dec  1,  00:00;  ’Job  0’ 


recv; 


Dec  1,  00:00:  ’Job  0’ 


exi  trans  fn(0  mtnuies,  ’Job  O’) 
ta?()  —*  100  minutes 
send: 


recv; 

send; 


recv; 

Dec  1,  01:40 

send:  ^ 

Dec  1,  00:00;  ’Job  0’ 

'  Dec  1,  00:00;  ’Job  0’ 

Dec  1,  00:00;  ’Job  0’ 

recv;  ^ 

Dec  1,  00:00:  ’Job  0’ 

[’) 

ext  trans  fn(0  minutes,  ’Job  i 

Dec  1,  01:40 


ta?()  —*  5  minutes 


recv: 

send; 


Done 


d:  Dec  1,  00:05 

Dec  1,  00:05 

'  Dec  1,  00:05 

send: 

'  Dec  1,  01:40 

int  trans  fn()  -+  #aciivt 
ta?{)  — ♦  10  mtnuies 
send:  Dec  1,  00:10 


Donc\ 


recv; 
send; 


Dec  1,  00:10 


Done 


recv: 


recv: 

send: 
Donei 


Dec  1,  00:10 


Dec  1,  00:10 


Dec  1,  00:05 


Dec  1,  00:05 


Time:  Dec  1,  00:05 
send: 


Dec  1,  00:05 

recv:  *j 

Dec  1,  00:05 

send:  * 

Dec  1,  00:05 

1  _____ 

recv:  *j 

Dec  1,  00:05 

outpui?()  — * 

’Job  O' 

send:  ^ 

Dec  1,  00:05: 
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send: 


^1  Dec  1,  00:05.  ’Job  0’ 

"’[Dec  1,  00:05:  ’Job  0’ 

recv:  •'j 
send:  * 

Dec  1,  00:05:  ’Job  0’ 

Dec  1,  00:05:  ’Job  0’ 

recv:  * 

Dec  1,  00:05:  Mob  0’ 

exi  irans  fn(5  minutes,  ‘Job  O’) 
ta?()  —>  95  minutes 
send: 


recv: 

send; 

Dec  1,  01:40 

Dec  1,  00:10 

recv: 

Dec  1,  00:10 

send: 

Dec  1,  00:10 

int  trans  fn()  — *■  ; 

#busy 

Dec  1,  01:40 


ta?()  — ►  forever 


send; 

Infinity 

recv; 

send; 

Infinity 

Dec  1,  00:10 

recv;  Dec  1,  00:10 

Time:  Dec  1,  00:10 

send:  ‘  Dec  1,  00:10 


recv: 

send: 


Dec  1,  00:10 


Dec  1,  00:10 


recv: 

send: 


Dec  1,  00:10 


Dec  1,  00:10 


recv; 


Dec  1,  00:10 


output?()  — ►  ’Job  1’ 


recv;  *' 
send: 


send;  ^ 

Dec  1,  00:10;  ’Job  1’ 

Dec  1,  00:10:  ’Job  1’ 

1 

’  Dec  1,00:10;  ’Job  1’ 

1 

recv:  * 

Dec  1,  00:10:  ’Job  1’ 

ext  trans  fn(5  minutes,  'Job  1’) 
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la?()  — *  90  minutes 
send: 


recv:  * 
send:  ^ 


rec.-:  Oo"' 

Dec  1,  01:40 

send: 

Dec  1,  00:10:  ’Job  1’ 

Dec  1,  00:10:  ’Job  1’ 

Dec  1,  00:10:  ’Job  1’ 

recv:  ' 

Dec  1,  00:10;  ’Job  1’ 

Dec  1,  01:40 


exi  trans  fn( 5  minutes,  ’Job  I’) 
ta?()  — ►  5  minutes 


send: 

_ 1 

Dec  1,  00:15 

recv: 

Dec  1, 

00:15 

send: 

Dec  1,  00:15 

send: 

=  Dec  1,  01:40 

recv: 


«nt  trans  fn()  — »  ^active 
ia?()  — ♦  10  minutes 
send:  °°”‘'|Dec  1,  00:20 

Donei 


Dec  1,  00:20 


send 


.  Done] 


Done 


recv: 


recv: 
send: 

Done 


Dec  1,  00:20 


Dec  1,  00:20 


Dec  1,  00:15 


Dec  1,  00:15 


Time:  Dec  1,  00:15 
send:  ’ 


Dec  1,  00:15 

recv:  *j 

Dec  1,  00:15 

send:  ‘ 

Dec  1,  00:15 

1 _ 

recv:  * 

Dec  1,  00:15 

output?()  — ♦ 

'Job  r 

•  y 


recv 

send: 


send:  «  Dec  1,00:15:  ’Job  1’ 

Dec  1,  00:15:  ’Job  1’ 

1 _ 

Dec  1,  00:15:  ’Job  1’ 

recv: 

send:  ® 

Dec  I,  00:15:  ’Job  1’ 

Dec  1,  00:15;  ’Job  1’ 
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recv:  ^  Dec  1,  00:15:  Mob  1’ 
ext  trans  fn( 5  minutes,  'Job  I') 
ta9()  — ►  85  minutes 
send:  ^“"'1  Dec  1,  01:40 


recv: 

Dec  1,  01:40 

send: 

Dec  1,  00:20 

recv:  Dec  1,  00:20 

send:  Dec  1,  00:20 

int  trans  fn()  — ►  #busy 
ta?()  —  forever 


send: 

recv:  Infinity 

send:  ^‘’"*1  Dec  1, 


Infinity 


Dec  1,  00:20 


recv:  Dec  1,  00:20 

Time:  Dec  1,  00:20 


A  similar  pattern  of  messages  intervenes 


Time:  Dec  1,  01:35 
send:  *  Dec  1,  01:35 

recv:  *  Dec  1,  01:35 
send:  *  Dec  1,  01:35 

recv;  *  Dec  1,  01:35 
output? 0  —*  'Job  9 
send:  ^  Dec  1,  01:35;  Mob  9’ 
recv:  »]  Dec  1,  01:35:  Mob  9’| 
send:  '|  Dec  1,  01:35;  Mob  9’ 

recv:  iDec  1.  01:35:  Mob  9~ 
send:  *  Dec  1,  01:35;  Mob  9’ 

recv;  ^  Dec  1,  01:35;  Mob  9’ 
ext  trans  fn(5  minutes,  'Job  9’) 
ta?()  — «  5  minutes 
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send;  ^<’"'1  Dec  1,  01:40  I 


recv: 

Dec  1,  01:40 

send: 

'  Dec  1.  01:40 

recv:  Dec  1,  01:40 

send:  Dec  1,  01:40 

int  irons  fn()  — » 

#busy 

ta?()  — •  forever 
send;  Infinity 
recv:  Infinity 

send;  Dec  1.  01:40 

recv;  ^°"«|Dec  1,  01:40 1 

Time:  Dec  1,  01:40 
send;  *|^Dec  1,  01:40 

recv:  *  Dec  1,  01:40 
send:  *  Dec  1,  01:40 

recv;  *  Dec  1,  01:40 
send;  *  Dec  1,  01:40 

recv:  *  Dec  1,  01:40 
output? 0  — *  'Job  10’ 
send:  y|  Dec  1,  01:40:  ’Job  10’ 
recv;  s'  Dec  1,  01:40:  ’Job  10’ 
send:  Dec  1,  01:40:  ’Job  10’ 

recv:  *  Dec  1,  01:40:  ’Job  10’ 
ext  irons  fn(5  minutes,  ’Job  10’) 
ta?()  — »  0  minutes 
send;  Dec  1,  01:40 
recv;  ^‘”’*1  Dec  1,  01:40 1 
send:  y|  Dec  1,  01:40:  ’Job  10~ 
recv:  ^  Dec  1,  01:40:  ’Job  10’ 
send:  ®  Dec  1,  01:40;  ’Job  10’ 

recv;  ^  Dec  1,  01:40:  ’Job  10’ 
ext  trans  fn(5  minutes,  ’Job  10’) 
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recv; 


ta'^O  —  5  minutes 


send: 

Dec  1 

,  01:451 

recv: 

Dec  1,  01:45  1 

send: 

Dec  1,  01:45 

send: 

^  Dec  1,  01  40j 

int  Irans  }n()  — •  ^active 
la'^(}  lO  minutes 


sen 

Done 

!  Dec  1.  01  50  i 

recv: 

Dec  1, 

01  50  1 

f 

send: 

Dec  1. 

01.40  I 

recv: 

Dec  1 

.  01:40j 

sen 

Dont 

Dec  1 

,  01:40 

1 

Don<j 

1 

Dec  1, 

01:40 

Time:  Dec  1,  01:40 
send 


1  Dec  1.  01:40 

recv:  *[ 

Dec  1,  01:40  j 

send;  * 

Dec  1,  01:40 

recv:  * 

Dec  1,  01:40| 

send.  ' 

jDec  1,  01:401 

1 _  1 

Dec  1,  Ol  iOl 


outputyf ) 


■j  minutes 


send:  ^ 

Dec  1.01 .40:  5  minutes 

recv:  S'! 

Dec  1, 

01:40:  5  minutes  | 

send:  ^ 

Dec  i,  01:40:  5  minutes  j 

recv:  *■ 

Dec  1,  01:40: 

5  minutes  i 

ezl  Irons  fn(0  minules.  5  minutes} 
ta?()  — >  forever 


send:  Infinity  | 

recv:  Infinity 

send:  ^  Dec  1.  01:40:  5  minutes  i 

recv: 

send:  ^ 

Dec  1,  01:40:  5  minutes 

Dec  1,  01:40:  5  minutes 
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in/  irans  fn()  — •  ^active 
ta?()  — •  forever 
send:  ^“"'1  Infinity  I 


Time:  Dec  1,  01:45 
send:  *  Dec  1,  01:45 

recv:  *  Dec  1,  01:45 
send:  *  Dec  1,  01:45 

recv:  *  Dec  I,  01:45 

ouipui?()  — »  'Job  10’ _ 

send;  ^  Dec  1,  01:45;  ’Job  10’ 
recv:  ^  Dec  I,  01:45:  ’Job  10’ 
send:  Dec  1,  01:45:  ’Job  10’ 

recv:  *  Dec  1,  01:45;  ’Job  10’ 
send:  ^  Dec  1,01:45:  ’Job  10’ 

recv;  '  Dec  1,  01:45:  'Job  10' 
ext  leans  fn(5  minutes.  'Job  10') 


ta?()  — ‘  forever 
send:  Infinity 


recv:  Infinity 

send:  Infinity 

recv:  Infinity 

send;  Infinity 

int  trans  fn()  —►  #busy 
ta?()  — •  forever 
send:  Infinity 
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Dec  1.  00:00:  ’Job  0 
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Chapter  3 

System  Design 


VVe  chose  to  use  DEVS  [Zei90]  as  the  methodology  for  constructing  the  simu¬ 
lation  components  of  our  system.  The  DEVS  methodology  is  modular  and  hi¬ 
erarchical,  supporting  the  development  of  independent  models  that  are  linked. 
An  implementation  in  Scheme,  an  object-oriented  programming  language  based 
on  Lisp,  is  described  in  [Zei90]  and  was  to  be  the  basis  for  our  implementation. 

DEVS-Scheme  was  also  attractive  because  it  was  developed  with  running  on 
multicomputers  in  mind[Zei90,  p.  62]: 

. .  .The  implementation  in  DEVS-Scheme  has  the  characteristics 
of  a  “virtual  multiprocessor”  in  that  each  of  the  processor  objects 
could  in  principle  be  assigned  to  a  different  physical  computer.  This 
renders  modelling  in  DEVS-Scheme  a  natural  basis  for  implementing 
discrete  event  models  on  multi-computer  architectures. 

We  were  interested  in  being  able  to  run  our  cutting  room  simulations  in  a 
multiprocessor  environment  because  we  expected  them  to  take  quite  a  while 
to  complete  when  run  on  a  desktop  computer.  Part  of  our  project  was  to 
examine  ways  to  distribute  the  simulation.  Research  on  distributing  DEVS- 
Scheme  would  simplify  that  task  for  us.' 

The  system  comprises  three  main  categories  of  classes: 

•  DEVS  classes 

•  application  classes 

•  user  interface  classes 

*  Because  of  our  significant  underestimation  of  the  programming  effort  required  for  our 
simulation,  we  did  not  get  a  chance  to  investigate  distribution  of  simulator  components.  \N'e 
note  that  execution  time  on  a  Macintosh  (M68040  processor)  running  Objectworks\Smallt3lk 
(Version  4.1),  the  machine  and  progr2unming  language  environment  used  for  development,  is 
acceptable  for  at  least  the  small  test  simulations  we  have  run. 
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A  description  of  the  main  classes  in  each  of  these  categories  is  provided  in  the 
next  three  sections.  The  remaining  sections  in  this  chapter  provide  descriptions 
of  support  for  debugging  and  testing. 


3.1  DEVS  Implementation  in  Smalltalk-80 

Our  implementation  of  DEVS  in  Smalltalk-80  pMailels  Zeigier’s  implementation 
in  Scheme,  but  differs  in  some  aispects  arising  primarily  from  a  different  perspec¬ 
tive  on  the  application  of  object-oriented  technologies.  Zeigier’s  implementation 
was  influenced  by  the  view  of  objects  presented  by  Scheme.  His  approach  is  to 
define  a  class,  then  alter  the  contents  of  that  class  as  appropriate  for  a  particu¬ 
lar  model.  For  example,  the  simple  processor  model  we  discussed  earlier  would 
be  an  instance  of  class  AtomicModel  whose  list  of  state  variables  is  augmented 
by  joblO  and  processingTime  to  represent  the  processor’s  state.  Our  approach 
uses  subclassing;  a  class  SimpleProcessor  is  a  subclass  of  a  class  AtomicModels, 
inheriting  the  state  variables  and  methods  required  to  be  an  atomic  model,  then 
adding  in  new  instance  variables  and  methods  to  simulate  the  state  and  behav¬ 
iors  of  a  simple  processor.  Our  approach  is  cleaner  from  a  programming  v’cw, 
but  a  little  further  removed,  perhaps,  from  the  DEVS  formalism.  For  example, 
time  advance  is  no  longer  a  function  (object),  but  is  a  method  provided  by  a 
model  object. 

The  implementation  that  we  describe  has  evolved  from  an  initial  implemen¬ 
tation  that  was  faithful  to  the  Scheme  implementation.  As  we  began  to  figure 
out  how  a  DEVS  simulation  worked,  we  began  to  refine  our  implementation  so 
that  it  became  easier  to  create  models.  Our  goal  is  to  make  the  addition  of  new 
classes  of  objects  that  represent  cutting  room  resources  as  straightforward  as 
possible.  As  work  progressed,  we  revised  Zeigier’s  design  to  suit  our  needs.  Over 
the  term  of  the  project,  we  reimplemented  significant  portions  of  the  classes  sve 
describe  at  least  two  times.  Our  implementation  could  probably  use  one  more 
good  review  to  flush  out  the  remnants  of  the  original  design.  We  didn't  want 
to  take  the  time  away  from  using  these  classes  to  implement  simulations,  so  we 
never  gave  ourselves  an  opportunity  for  another  review. 

We  have  restricted  our  implementation  to  include  only  those  classes  that 
we  need  for  C£IP  simulations — namely,  the  only  coupled  models  we  use  are 
digraph  models.  We  have  used  the  same  class  hierarchy  and  have  defined  the 
same  set  of  support  classes.  However,  we  have  extended  the  Scheme  implemen¬ 
tation  with  respect  to  how  we  handle  time  and  with  respect  to  how  we  handle 
instance  variaoles.  We  have  also  added  a  special  kind  of  digraph  model  that 
supports  dynamic  change  to  the  composition  tree.  In  this  section  we  describe 
our  implementation  of  DEVS  in  Smalltalk-80.  Class  specifications  for  all  the 
classes  described  here  may  be  found  in  Appendix  A. 

Detailed  descriptions  and  specifications  of  DEVS  and  application  clas.ses 
described  in  the  remainder  of  this  chapter  are  provided  in  Appendices  and  B, 
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Entities  ('name'  'parent') 

Models  ('processor'  inport'  outport’) 

AtomicModel  ('x'  'y'  'sigma'  'phase'  e') 

CoupledModeis  ('receivers'  'influencees'  'priorityList') 

DigraphModeis  ('compositionTree'  'influenceDigraph'  'selectFn') 
DynamicDigraphModels  () 

Processors  ('devsComponent'  'childProcessors'  timeOfLastEvent'  timeOfNextEvent  ) 
Coordinator  ('starChild'  'waitlist'  tNChildren  ) 

DynamicCoordinator  () 

RootCoordinator  ('clock'  'child'  'startTime'  'timelimit') 

Simulators  () 


Figure  3.1;  The  DEVS  class  hierarchy.  (Instance  variables  are  shown  in  paren¬ 
theses.) 


3.1.1  DEVS  Entities 

The  hierarchical  structure  of  classes  for  DEVS  entities  is  shown  in  figure  31. 
Class  Entities  is  common  to  all  DEVS  classes^.  This  class  corresponds  to  Zei- 
gler’s  class  of  the  same  name  and  is  as  an  abstract  class,  holding  the  common 
attributes  of  its  subclasses.  The  common  attributes  are  the  name  of  the  entity 
and  the  parent  of  the  entity.  Zeigler  does  not  include  the  parent  in  this  class,  but 
duplicates  it  in  subclasses.  We  have  elevated  this  common  attribute  to  the  En¬ 
tities  class.  Zeigler  includes  a  list  of  instances  in  his  Entities  class,  but  Smalltalk 
maintains  the  list  of  instances  for  us  so  we  don’t  include  it.  Below  Entities  in 
the  hierarchy  are  Models  and  Processors  corresponding  to  DEVS  models  and 
processors,  respectively. 

Models 

The  abstract  class  of  models  comprises  two  main  subclasses:  AtomicModels  and 
CoupledModeis.  Common  attributes  of  these  subclasses  are: 

•  processor — the  processor  attached  to  the  model  during  a  simulation  run. 

•  inport— a,  list  of  the  input  ports  for  the  model. 

•  outport — a  list  of  the  input  ports  for  the  model. 

^We  have  not  shown  it  here,  but  Entities  is  a  subclass  of  Smalltalk's  Model  class,  allowing 
us  to  make  any  DEVS  model  a  component  of  the  Model/View/ControUerframework.  We  will 
discuss  this  more  fully  in  regard  to  the  design  of  the  user  interface. 
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Zeigler  includes  attribute  cell  position  in  this  class,  but  that  attribute  is  associ¬ 
ated  with  kernel  models,  a  class  of  model  that  we  don’t  support^. 

We  require  each  model  subclass  to  provide  a  restart  method  that,  when 
dispatched,  initializes  the  model  to  some  base  state  and  answers  the  duration 
to  the  next  internal  transition.  Zeigler  seems  to  use  a  method  initialize  for 
this  purpose,  but  we  reserve  the  method  initialize  for  the  more  conventional 
application  of  initializing  an  instance  upon  creation.  Use  of  a  separate  restart 
operation  allows  us  to  construct  a  hierarchy  of  models  once  and  restart  all  its 
components  any  number  of  times  for  a  variety  of  simulation  runs.  By  convention, 
any  subclass  of  Models  that  overrides  restart  should  include  “super  restart”  as 
part  of  the  method’s  definition. 

Atomic  Models  Atomic  models  comprise  the  leaves  of  the  hierarchical  con¬ 
struction  of  models  in  the  DEVS  methodology.  Recall  that  an  atomic  model  is 
characterized  by  state  variables  (sigma  and  phase),  an  internal  transition  func¬ 
tion,  an  external  transition  function,  an  output  function,  and  a  time  advance 
function.  In  our  implementation,  state  variables  are  represented  by  instance 
variables  and  the  functions  are  represented  by  methods.  Every  instance  of 
AtomicModel  has  instance  variables  phase  and  sigma  and  four  methods: 


intTransFn 

extTransFn:  aTime 

externalinput:  aContent 
outputFn 

timeAdvanceFn 


implements  the  internal  transition  function 
implements  the  external  transition  function 


implements  the  output  function 
implements  the  time  advance  function 


We  have  omitted  the  state  parameter  from  all  of  the  functions  because  in  our 
design,  each  model  maintains  its  own  private  state.  Nor  do  the  transition  func¬ 
tions  return  a  state.  Instead,  these  functions  modify  the  state  of  the  model 
on  which  they  are  applied.  Zeigler’s  design  represents  each  of  these  functions 
as  a  lambda  expression  (Lisp  function)  separate  from  a  instance  and  therefore 
each  requires  a  state  parameter  to  establish  a  context  in  which  the  function  is 
evaluated.  His  design  arises  from  the  way  in  which  Scheme  associates  methods 
with  instances.  Smalltalk  lets  us  use  a  much  simpler  design. 

All  functions  except  for  the  time  advance  function  must  be  implemented  by 
subclasses  of  AtomicModel.  The  time  advance  function  defined  in  class  Atomic- 
Models  answers  the  current  value  of  sigma.  In  most  cases,  this  behavior  is  the 
one  needed,  so  this  function  definition  is  seldom  overridden.  An  AtomicModel 
instance  has  three  state  variables  that  are  maintained  internally: 

^In  DEVS,  a  coupled  model  can  be  either  a  digraph  model  or  a  kernel  model  (in  which  all 
its  component  models  eure  of  the  same  class).  In  CflP  ,  we  have  needed  only  digraph  models, 
so  DigraphModels  is  the  only  subclass  of  CoupledModels  that  appears  in  the  hierarchy. 
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e  the  elapsed  time  in  the  current  state 
X  the  external  input  causing  the  most  recent  event 
y  most  recently  generated  content  for  output 

Access  methods  exist  to  read  and  write  each  of  these.  Variables  e  and  x  are  set 
when  the  external  transition  function  is  dispatched.  Variable  y  is  set  when  the 
output  function  is  dispatched. 

The  useful  actions  taken  by  atomic  models  are  implemented  as  macros  in 
DEVS-Scheme  amd  as  methods  in  class  AtomicModel: 

Action  Method 

hold-in  phase  for  duration  holdtn:  aPhase  for  Time:  aDuration 

passivate  in  phase  passivatein:  aPhase 

passivate  passivate 

continue  continue 

Two  macros  supporting  the  generation  of  output  are  also  implemented  as.  meth¬ 
ods  in  the  class: 


Action  Method 

send  value  to  port  send:  aValue  toPort:  aPort 

noOutput  noOutput 

An  instance  of  AtomicModel  is  created  using  the  class  method  new:  aString 
or  using  class  method  makePair;  aString,  where  aString  designates  the  model’s 
name.  The  latter  method  automatically  attaches  a  simulator  to  the  model.  The 
name  given  the  simulator  is  the  name  of  the  model  prefixed  by  “S:”. 

Coupled  Models  Coupled  models  comprise  the  internal  nodes  of  the  hierar¬ 
chical  construction  of  models  in  the  DEVS  methodology.  These  models  supply 
the  mechanism  for  building  complex  models  from  simpler  models.  Class  Cou- 
pledModels  serves  to  establish  a  common  protocol  for  all  kinds  of  coupled  models. 
The  information  in  an  instance  is: 
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children 

receivers 


influencees 


priority  List 


the  set  of  component  models, 
associates  an  input  port  of  this  model 
with  the  children  who  are  connected  to 
it. 

connections  between  children's  output 
ports  and  input  ports.  Each  component 
is  a  coupling. 

used  to  break  ties  resulting  from  two 
children  having  the  same  time  to  next 
event.  The  first  child  in  this  list  has 
highest  priority.  The  select  function  (p. 
56)  uses  this  list. 


The  first  three  instance  variables  appear  in  the  DEVS-Scheme  implementation. 
Our  implementation  includes  a  priorityList  that  orders  the  children.  The  default 
select  function  definition  uses  this  list  to  determine  the  order  in  which  transition 
functions  are  invoked  on  children  models  that  are  ready  at  the  same  simulation 
time — the  earlier  a  model  appears  in  the  list,  the  higher  its  priority.  A  subclass 
can  override  this  behavior  by  defining  its  own  seiectFn. 

Method  getChildren  answers  the  children  of  the  re'-eiver — the  collection  of 
models  in  the  receiver’s  children  instance  variable.  The  following  methods  are 
specified  by  class  coupledModels  to  be  provided  by  subclasses: 


getReceivers  answers  a  list  of  chji'iren  that  will  re¬ 
ceive  an  external  eisnl  input  to  the 
receiver. 

getlnfluencees  answers  the  list  of  children  to  which  the 
output  of  the  imminent  child  is  an  input. 
translate:model:  provides  port-to-port  translation — that 
is,  provides  the  input  port  to  a  model 
that  is  connected  to  a  specified  output 
port  of  another  model. 

While  DEVS  defines  a  variety  of  coupled  models,  our  implementation  focuses 
on  only  the  most  general  kind:  digraph  models.  Digraph  models  contain  a  het¬ 
erogeneous  mixture  of  children  and/or  non-regular  couplings  between  children 
(see  [Zei90,  Chapter  5]. 

In  CnP  ,  every  coupled  model  is  an  instance  of  a  subclass  of  class  Digraph- 
Models.  Class  DigraphModels  contains  the  fundamental  instance  variables  and 
behaviors  of  digraph  models.  Recall  that  a  coupled  model  is  characterized  by  its 
children  models  and  the  couplings  of  ports  between  the  children,  and  between 
the  model  itself  and  its  children  as  specified  by:  a  composition  tree,  an  influence 
digraph,  and  a  select  function.  In  our  implementation,  the  composition  tree  and 
the  influence  digraph  of  a  coupled  model  are  represented  by  instance  variables 
compositionTree  and  influenceDigraph,  reipeclively,  and  the  select  function  is 
represented  by  a  method,  seiectFn. 
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Processors 

The  class  Processors  has  three  subclasses  corresponding  to  the  three  kinds  of  pro¬ 
cessors  in  DEVS:  Simulator,  Coordinator,  and  RootCoordinator.  The  attributes 
common  to  these  subclasses  are  placed  in  Processors: 

•  devsComponent — -the  model  attached  to  this  processor  instance  during  a 
simulation  run. 

•  timeOfLastEveni — the  simulation  time  at  which  the  last  event  in  the  DEVS 
component  occurred. 

•  iimeOfNexiEveni~the  simulation  time  at  which  the  next  event  in  the 
DEVS  component  is  scheduled  to  occur. 

Each  Processors  instance  responds  to  a  restartAt:  aSimulationTime  message 
that  initializes  the  receiving  processor  and  its  DEVS  component  (via  a  restart 
message).  The  definition  for  this  method  is  a  subclass  responsibility.  The 
method  must  return  a  done  message  whose  time  supplies  the  simulation  times 
at  which  the  processor’s  DEVS  component  is  scheduled  for  its  next  internal 
transition. 

Our  implementation  of  message  passing  is  different  from  that  used  in  DEVS 
and  DEVS-Scheme  with  respect  to  the  handling  of  done  messages.  Instead  of 
a  processor  explicitly  sending  a  done  message  to  its  parent  processor,  a  pro¬ 
cessor  implicitly  sends  the  message  by  returning  it  as  the  reply  to  an  r  or  a 
*  message.  This  convention  we  have  adopted  has  the  cost  of  slowing  down  a 
concurrent  implementation  because  of  the  synchronization  involved  with  wait¬ 
ing  for  a  return  message,  but  has  the  benefit  of  simplifying  our  implementation, 
especially  since  we  could  dispense  with  managing  a  wait  list  in  coordinators. 
Our  implementation  is  slightly  more  efficient,  and  simpler,  than  that  used  in 
DEVS-Scheme. 

Simulators  Class  Simulators  instances  respond  to  the  receipt  of  x  and  done 
messages,  replying  in  either  case  with  a  done  message.  Messages  are  received 
via  messages  with  selectors  xMessage:  and  starMessage:,  respectively: 

•  xMessage:  anXMessage — verifies  that  the  message  time  lies  between  the 
time  of  the  last  event  and  the  time  of  the  next  event.  If  so,  then  the  receiver 
sends  its  DEVS  component  the  elapsed  time,  forwards  the  content  of  the 
x-message  to  the  model,  applies  the  model’s  external  transition  function, 
updates  the  local  time  of  last  event  and  time  of  next  event,  and  returns  a 
done  message  to  report  the  time  of  the  next  event. 

•  starMessage:  aStarMessage— checks  that  the  time  in  the  message  and  the 
time  to  next  event  agree.  If  so,  then  the  processor  gets  an  output  value 
from  its  DEVS  component  by  invoking  its  output  function  and  sends  the 
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value  in  a  y  message  to  its  parent  coordinator,  has  the  model  update  its 
state  via  its  internal  transition  funct  ion,  updates  the  local  time  of  last 
event  and  time  of  next  event  based  on  the  model’s  time  advance  function, 
and  returns  a  done  message  to  report  the  time  of  the  next  event. 

In  addition,  an  instance  responds  to  a  restartAt:  message: 

•  restartAt:  aSimulationTime — sets  the  time  of  last  event  to  the  time  indi¬ 
cated  in  the  message  and  sends  a  restart  message  to  its  DEVS  component. 
Based  on  the  duration  returned  by  the  model,  the  processor  sets  the  time 
to  next  event  and  replies  with  a  done  message  carrying  that  time. 

This  message  must  be  sent  before  a  simulation  can  be  run. 

Coordinators  A  class  Coordinator  instance  handles  the  processing  associ¬ 
ated  with  the  coupled  model  paired  with  it  as  its  DEVS  component.  Since  a 
coupled  model  contains  other  models,  each  connected  to  a  Processors  instance, 
a  coordinator  has  child  processors  determined  in  the  obvious  way.  It  is  these 
children  that  a  coordinator  manages — that  is,  simulation  is  effected  by  a  coor¬ 
dinator  managing  its  children  more  than  a  coupled  model  managing  its  children 
in  response  to  transitions. 

Each  Coordinator  instance  maintains  a  list  of  children  in  an  instance  variable, 
tNChiidren.  [The  name  was  invented  by  Zeigler.]  This  list  contains  done  mes¬ 
sages  rather  than  processors,  each  such  message  containing  a  simulation  time 
and  a  message  originator,  in  this  case  the  originator  being  one  of  the  coordina¬ 
tor’s  children.  The  messages  in  tNChiidren  are  sorted  in  increasing  order  of  the 
times  they  contain.  Only  one  message  for  each  child  can  appear  in  the  list. 

Each  coordinator  also  maintains  a  variable  naming  its  imminent  child,  starChild. 
The  imminent  child  is  set  each  time  a  *  is  received  and  processed.  This  child  is 
a  model — one  of  the  children  of  the  coordinator’s  DEVS  component. 

A  coordinator  responds  to  i  ,  *  ,  and  y  messages: 

•  xMessage:  anXMessage — verifies  that  the  message  time  lies  between  the 
time  of  the  last  event  and  the  time  of  the  next  event.  If  so,  then  the 
receiver  determines  which  of  its  children  have  an  input  port  connected  to 
the  port  on  which  the  external  input  is  arriving.  To  each  of  these  children, 
the  coordinator  sends  an  x  message  and  places  the  resulting  done  message 
into  its  local  tNChiidren  that  contains  a  list  of  done  messages,  sorted  by 
time.  Thus,  the  imminent  child  appears  at  the  front  of  this  list.  The  time 
of  the  last  event  is  updated  to  the  time  appearing  in  the  x  message,  and 
the  time  of  the  next  event  is  set  to  the  time  indicated  in  the  done  message 
appearing  at  the  front  of  tNChiidren. 

•  starMessage:  aStarMessage- — sets  starChild  to  the  imminent  child  from  tN¬ 
Chiidren  and  removes  that  child  from  the  list.  [Note  that  tNChiidren  is 
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sorted  by  simulation  time.  If  two  or  more  done  messages  at  the  front  of 
this  list  have  the  same  time,  then  the  select  function  of  the  DEVS  compo¬ 
nent  is  used  to  determine  which  child  is  imminent.]  Next,  the  *  message  is 
forwarded  to  the  imminent  child’s  processor  and  the  resulting  done  mes¬ 
sage  is  inserted  into  tNChildren.  A  wave  of  y  and  r  messages  ensue,  then 
the  coordinator  updates  its  time  of  last  event  to  the  time  in  the  ♦  message 
and  sets  the  time  of  the  next  event  based  on  the  time  in  the  message  at 
the  front  of  tNChildren. 

•  yMessage;  aYMessage — determines  the  other  models  within  the  DEVS 
component  that  are  influenced  by  the  output  produced  by  the  imminent 
child  and  routes  the  content  of  the  y  message  to  each  in  an  i  message 
to  its  processor.  The  list  tNChildren  is  updated  to  include  the  done  mes¬ 
sage  produced  by  each  such  send  of  an  x  message.  Next,  the  coordinator 
determines  whether  the  output  should  be  routed  to  the  parent  in  a  y 
message — that  is,  whether  the  output  generated  by  the  imminent  child 
is  also  an  output  of  the  coupled  model.  If  so,  then  the  output  value  is 
wrapped  in  a  y  message  and  sent  to  the  parent.  [The  returned  done  mes¬ 
sage  is  ignored.]  Finally,  a  done  giving  the  time  in  the  message  at  the  front 
of  tNChildren  is  constructed  and  returned  to  the  sender  of  the  y  message. 

In  addition,  a  coordinator  responds  to  a  restartAt;  message; 

•  restartAt:  aSimulationTime — sets  the  time  of  last  event  to  the  time  indi¬ 
cated  in  the  message  and  sends  a  restartAt:  message  to  each  of  the  proces¬ 
sors  for  the  component  models  of  its  DEVS  component.  Each  restartAt: 
message  is  responded  to  with  a  done  message  and  these  are  collected  in 
tNChildren.  Based  on  the  simulation  time  in  the  first  entry  in  this  list, 
the  processor  sets  the  time  to  next  event  and  replies  with  a  done  message 
carrying  that  time. 

This  message  must  be  sent  before  a  simulation  can  be  run. 

Root  Coordinators  A  RootCoordinator  instance  manages  a  simulation  run 
of  a  model  by  sending  a  sequence  of  *  messages  to  a  coordinator  to  which  it  is 
attached.  The  coordinator  is  the  root  of  a  model  hierarchy. 

A  simulation  is  constructed  by  attaching  a  coordinator  to  an  instance  of 
Root  Coordinator.  The  root  coordinator  must  first  be  sent  one  of  three  messages 
to  reset  the  simulation,  all  of  which  send  a  restartAt;  message  to  the  attached 
coordinator: 

•  restart — equivalent  to  self  restartAt;  (self  startTime),  where  startTime  is 
assumed  to  have  been  set  to  a  simulation  time  with  accessor  startTime: . 

•  restartAt:  aSimulationTime — equivalent  to  self  restartAt:  aSimulationTime 
andRunFor:  Duration  infinite. 
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•  restartAt:  aSimulationTime  andRunFor;  aDuration — establishes  a  start  lime 
and  an  end  time  for  a  simulation  run — that  is,  the  simulation  run  termi¬ 
nates  when  the  simulated  time  reaches  the  specified  start  time  plus  the 
specified  duration. 

A  simulation  run  actually  starts  when  a  root  coordinator  receives  a  simulate 
message. 

Since  a  root  coordinator  acts  as  a  parent  processor  for  a  coordinator,  it  can 
receive  y  messages  corresponding  to  the  output  of  the  model  paired  with  the 
coordinator.  In  our  implementation,  y  messages  are  simply  ignored. 

A  root  coordinator  also  contains  support  for  a  window  interface.  This 
support — in  the  form  of  processes  and  semaphores — is  discussed  in  detail  in 
connection  with  the  user  interface  (see  Chapter  3.3). 

3.1.2  Extensions 

In  our  design,  we  have  extended  DEVS  to  include  coupled  models  whose  compo¬ 
nents  vary  over  time.  While  this  may  violate  the  formalism  of  DEVS,  we  found 
it  useful  for  modeling  the  workstations  at  a  piece  of  equipment.  We  define  a 
workstation  to  be  a  portion  of  a  piece  of  equipment.  For  example,  a  spreading 
table  might  be  used  as  a  single  workstation  for  producing  a  long  spread,  and 
then  used  subsequently  as  two  workstations  for  working  on  two  spreads  simul¬ 
taneously.  Without  the  ability  to  vary  the  components  of  an  equipment  model, 
we  would  either  have  to  include  a  large  number  of  components — for  example, 
one  for  each  potential  workstation — or  we  would  have  to  implement  a  discrete 
event  simulation  algorithm  to  model  the  various  workstations  in  use  at  a  given 
time. 

We  have  restricted  our  extension  to  digraph  models,  using  the  term  dynamic 
to  describe  the  behavior.  The  implementation  of  a  dynamic  digraph  model  re¬ 
quires  the  cooperation  of  an  attached  coordinator  since  the  two  objects  work 
together  to  implement  the  behavior  of  any  digraph  model.  Consequently,  the 
conditions  under  which  a  coupled  model  can  change  its  components  are  re¬ 
stricted  to  those  that  maintain  the  integrity  of  the  coordinator  and  all  other 
processors  in  the  hierarchically  structured  simulation  whose  states  are  based  on 
the  state  of  this  coordinator.  We  use  a  subclass,  DynamicCoordinator,  to  effect 
changes  in  a  way  that  is  invisible  to  other  processors. 

Recall  that  a  coordinator  maintains  a  sorted  list  tNChildren  that  provides 
information  about  the  times  at  which  each  component  model  is  due  for  a  tran¬ 
sition.  One  entry  in  this  list  identifies  the  imminent  child,  and  the  time  of 
next  event  for  this  imminent  child  is  reported  by  a  coordinator  as  the  time  of 
next  event  for  the  coupled  model.  Thus,  any  change  within  the  model  must  be 
done  between  the  activation  of  the  processor  with  an  i  or  a  ♦  message  and  the 
subsequent  emission  of  a  done  message  by  the  coordinator. 

It  is  interesting  to  note  that  a  coordinator  does  not  send  x  messages  to  a 
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coupled  model,  but  rather  sends  such  messages  directly  to  its  component  models' 
processors  based  on  information  provided  by  the  coupled  model  in  messages  such 
as  getlnfluencees  and  getReceivers.  Consequently,  one  of  the  component  models 
must  take  responsibility  for  restructuring  the  components  of  a  coupled  model 
and,  in  fact,  this  model  must  be  an  atomic  model. 

An  atomic  model  might  want  to  change  a  digraph  model’s  component  struc¬ 
ture  at  any  transition  point,  corresponding  to  the  arrival  of  a  ♦  or  an  r  message 
to  the  coordinator  for  the  dynamic  coupled  model.  We  restrict  the  decision  to 
change  to  the  imminent  child,  an  atomic  model.  Consider  two  cases; 

1.  The  arrival  of  a  ♦  message  signals  the  occurrence  of  an  internal  transition 
and  is  forwarded  to  the  processor  corresponding  to  the  imminent  child  in 
the  form  of  a  *  message.  Since  the  imminent  child  is  an  atomic  model,  then 
its  simulator  will  invoke  its  output  function  and  pass  the  output  to  the 
simulator’s  parent,  then  invoke  the  model’s  internal  transition  function, 
and  then  invoke  the  time  advance  function.  Based  on  this  time  as  pro¬ 
vided  in  a  final  done  message  provided  to  the  coordinator,  the  coordinator 
determines  the  schedule  for  this  atomic  model’s  internal  transition. 

If  the  atomic  model  wishes  to  restructure  the  digraph  model,  then  it  must 
do  so  when  it  is  the  imminent  child,  and  it  must  take  responsibility  for  up¬ 
dating  the  state  of  the  coordinator.  It  must  preserve  itself  as  the  imminent 
child  and  is  allowed  only  to  change  the  internal  and  external  couplings, 
including  removing  and  adding  components  in  the  process. 

2.  The  arrival  of  an  z  message  signals  the  occurrence  of  an  external  transition. 
The  message  is  distributed  to  all  component  models  connected  to  the  input 
port  on  which  the  message  arrives.  The  processing  required  is  the  same 
as  described  above  for  a  ♦  message. 

Thus,  an  atomic  model  can  restructure  the  dynamic  coupled  model  con¬ 
taining  it,  but  can  do  so  only  as  an  imminent  child  and  by  preserving  itself  as 
the  imminent  child.  Consequently,  a  dynamic  model  will  typically  contain  an 
atomic  model  that  acts  as  a  manager  for  the  model — essentially  a  model  that 
monitors  the  activities  of  the  other  components  and  activates  itself  by  becom¬ 
ing  the  imminent  child,  taking  appropriate  action,  and  returning  to  a  passive, 
monitoring  state. 

This  design  violates  the  rr.odularity  of  DEVS  because  certain  atomic  models 
are  aware  of  their  status  as  a  component  in  a  coupled  model.  A  better  design 
would,  perhaps,  make  what  we  have  described  as  a  manager  a  part  of  the  coupled 
model  itself  and  somehow  coordinate  more  closely  with  the  coordinator.  Our 
approach  is  bcised  on  the  way  in  which  coordinators  interact  directly  with  the 
processors  of  component  models  of  a  coupled  model. 

Independent  of  the  best  way  to  include  these  capabilities,  it  is  clear  that 
DEVS  as  defined  was  not  sufficiently  powerful  in  providing  the  functionality  we 
needed  to  handle  multiple,  dynamically  varying  workstations  within  equipment 
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models  Our  lesigii  of  dyiiamu:  enlilw's  addresst-s  llu-  pri<hl'*iii  !■>  <-xit-udiiu.’, 

DEVS. 

3.1.3  Support  Classes 

number  of  classes  have  been  defined  to  support  the  DEVS  entuies  .uid  simu¬ 
lation.  These  classes  are  presented  in  thus  section. 

DEVS  Messages 

The  four  types  of  messages  used  to  coordinate  processing  during  a  suniilation 
run  ate  structured  as  follows: 

DEVSMessage  ('source'  time  ) 

DEVSlOMessage  (  content  ) 

XMessage  () 

'YMessage  () 

DoneMessage  () 

StarMessage  () 

This  organization’s  structure  reflects  the  fact  that  liont:  and  •  messages  carry- 
no  content.  .\11  messages  carry  a  timestamp  and  the  processor  that  originated 
the  message.  The  time  stamp  is  an  instance  of  cla-ss  SlmuiationTime  (see  section 
3.1.3).  The  model  is  an  instance  of  class  Processors 

A  message  content  is  represented  by  an  instance  of  class  Content  .A  conteru 
hai?  two  attributes:  a  port  and  a  value.  The  value  is  generated  by  a  model  and 
can  be  any  object.  A  port  is  an  instance  of  class  Port  which  designates  a  model 
and  a  port  name.  The  name  of  a  port  is  alway.s  represented  as  a  Smalltalk 
symbol — for  example,  ?jtln.  A  port  can  be  constructed  by  sending  a  roinina 
message  to  a  model — for  example.  (M  ,  p)  creates  an  instance  designating  port 
p  of  model  M. 

We  note  that  at  some  points  during  a  simulation,  a  proces,sor  might  bi- 
required  to  send  a  y  message  even  though  no  output  is  available,  Like  Zeigler, 
we  represent  a  null  content  explicitly — that  is,  as  a  Content  instance  that  ha.s 
null  port  and  value  attributes. 

Model  Components 

The  structure  of  a  digraph  model  is  represented  by  an  instance  of  Composi- 
tionTree  that  specifies  the  coupling  among  the  component  models.  .\n  instance 
represents  a  specific  composition  tree  as  defined  in  fZeiOO,  pp  ‘2911.  p  •')<)]  F’ro- 
tocol  provided  for  an  instance  supports  the  construction  of  the  tree  and  the 
querying  of  the  structure  and  various  couplings.  Note  that  Zeigler  is  not  clear 
about  where  coupling  information  is  stored.  We  have  selected  to  .store  it  m  the 
composition  tree.  An  instance  has  five  components. 
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the  root  of  the  compoittion  tree 
the  (eaves  of  the  composition  tree, 
the  external  input  coupling  which  con¬ 
nects  the  input  ports  of  the  coupled 
model  to  one  or  more  of  the  input  ports 
of  the  components — this  directs  inputs 
received  by  the  coupled  model  to  desig¬ 
nated  component  models, 
the  external  output  coupling  which  con¬ 
nects  output  pons  of  components  to  out¬ 
put  ports  of  the  coupled  model— thus 
when  an  output  is  generated  by  a  compo¬ 
nent  it  may  be  sent  to  a  designated  out¬ 
put  port  of  the  coupled  model  and  thus 
be  transmitted  externally, 
the  internal  coupling  which  connects 
output  ports  of  components  to  input 
ports  of  other  components— when  an  in¬ 
put  IS  generated  by  a  component  it  may 
be  sent  to  the  input  ports  of  designated 
components  fin  addition  to  being  sent  to 
an  output  port  of  the  coupled  model). 

A  coupling  is  represented  as  an  instance  of  class  Coupling  which  is  sirnpiy  an 
ordered  pair  of  ports  designated  as  the  from  port  and  the  to  port. 

Simtilatioa  Time 

In  his  description  of  DEVS  Scheme,  Zeigler  is  vague  with  respect  to  simulation 
time.  In  all  of  his  examples,  lime  is  represented  as  an  integer  value  that  starts 
at  zero  and  progresses  toward  (positive)  infinity,  which  is  represented  by  the 
Lisp  atom  'inf.  This  representation  of  time  was  not  useful  for  us:  we  needed 
to  keep  track  of  date  and  time  of  day  because,  for  example,  an  operator's  work 
schedule  is  a  significant  factor  in  determining  when  a  task  is  completed  or  when 
an  event  in  a  model  might  occur — for  example,  a  shift  change.  As  a  result,  we 
decided  to  treat  simulation  time  more  formally  and  model  it  in  a  class.  As  such, 
we  have  modeled  two  aspects  of  time:  a  simulation  time  and  a  duration. 

A  simulation  time  is  a  specific  date  and  time — for  example.  1:00  A.M.  on  1 
January  1993.  All  times  are  tracked  to  the  minute.  We  decided  to  ignore  seconds 
since  it  is  doubtful  that  any  meaningful  results  would  come  out  of  tracking 
seconds  in  a  simulation.  A  special  simulation  time  is  Infinity,  indicating  a  time 
very  far  in  the  future. 

We  distinguish  a  simulation  time  as  just  described  from  a  duration  of  time,  A 
duration  is  a  length  of  time — for  example,  five  minutes  or  ten  days.  .\11  models 
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maintain  sigma  as  a  duration.  An  infinite  duration  is  sometimes  ilenotoi  ;i.s 
forever. 

Some  arithmetic  operations  are  defined  on  simulation  times  and  durations 


SimulationTime  —  SimulationTime 
SimulationTime  +  Duration 
SimulationTime  —  Duration 
SimulationTime  +  Duration 
SimulationTime  -  Duration 
Duration  +  Duration 
Duration  —  Duration 
Duration  +  SimulationTime 


Duration 

SimulationTime 

SimulationTime 

SimulationTime 

SimulationTime 

Duration 

Duration 

SimulationTime 


If  any  of  the  operands  are  infinity  or  forever,  then  the  result  is  itdimiy  or  fofio,.'r 
as  appropriate.  Relational  operators  for  comparing  two  Simula  loii  times  !>r  two 
durations  are  also  defined.  Comparing  infinity  to  infinity,  or  forever  to  f<.trever. 
is  undefined. 

Our  use  of  these  classes  was  a  convenience  in  coding  up  our  models  of  cult  mg 
room  resources.  We  augmented  the  predefined  Smalltalk  chiss  Number  with  a 
set  of  methods  to  facilitate  the  creation  of  durations.  Tiic  messages  minute{s). 
day(s),  week(s),  and  month(s)  sent  to  a  number  answer  a  duration 

The  classes  associated  with  simulation  time  and  duration  are:  Simulation- 
Time,  Infinity,  Duration,  and  InfiniteDuration.  Class  descriptions  may  be  found 
in  the  appendix. 


Miscellaneous  Classes 

Just  as  we  found  it  convenient  to  define  rlas.ses  to  model  .>miiilai ion  time,  we 
defined  classes  to  represent  lengths — inches,  feet,  and  yards.  Cla.s.s  Length  em¬ 
bodies  this  concept.  As  in  the  case  of  Duration,  we  have  added  method.'!  to  r|a.ss 
Number  to  facilitate  the  creation  of  lengths — for  example.  3  yards  produces  an 
instance  of  length.  Arithmetic  is  also  defined  for  lengths — adding  .and  subtract¬ 
ing  lengths  is  supported  as  is  multiplying  and  dividing  lengths  by  a  number  We 
do  not  support  the  multiplication  or  division  of  two  lengths  (We  didn't  want 
to  get  involved  m  tracking  units — for  e.xampie.  recognizing  that  the  proiJufi 
of  two  lengths  is  an  area — because  it  was  not  necessary  for  the  sumilaliuiis  we 
were  trying  to  construct.]  The  class  description  for  Length  may  be  fomnl  m  the 
appendix. 


3.2  Application  Classes 

Application  clas.ses  compri.se  those  subc|as,ses  of  Models  representing  the  ‘  Ut- 
ting  room  and  its  resources.  The  mam  kin<ls  of  models  in  the  ciiUing  room 
application  fall  into  four  mam  categories: 
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•  Plans  and  tasks 

•  Cutting  room 

•  Equipment  and  workstations 

•  Resources 

We  describe  each  of  the  main  classes. 

The  classes  in  the  hierarchy  relating  to  application  objects  is  highlighted  in 
Figure  3.2.  Note  that  the  class  Entities  is  a  subclass  of  Model'*.  This  allows  any 
DEVS  entity  to  be  used  as  a  model  in  connection  with  views  <is  described  in 
Section  3.3. 

3.2.1  Plans  and  Tasks 

The  simulation  is  controlled  by  a  plan  that  details  the  tasks  to  be  performed 
and  the  operators  and  materials  assigned  to  perform  them.  The  purpose  of  a 
simulation  run  is  to  model  the  result  of  the  plan  in  a  particular  cutting  room. 

A  plan  is  a  sequence  of  work  assignments.  Each  work  assignment  comprises 
a  task,  operators  to  perform  the  task,  and  a  workstation  on  which  the  task  is 
to  be  performed.  Operators  can  be  specified  to  perform  a  task  individually  or 
together  with  one  or  more  others.  Additionally,  several  alternative  assignments 
are  possible  so  that,  for  example,  one  of  several  operators  might  perform  the 
task,  depending  on  availability*.  A  task  is  a  description  of  a  job  to  be  performed, 
including  one  or  more  materials  to  be  used  for  the  task.  For  example,  a  task 
might  be  to  spread  thirty  5-yard  layers  of  white  cotton  fabric,  taking  the  fabric 
from  two  specific  rolls.  A  work  assignment  would  associate  that  task  in  llie 
plan  with  an  operator  and  a  workstation.  A  workstation  is  simply  a  portion  of 
a  piece  of  equipment — for  example,  the  spreading  task  might  be  performed  on 
the  left  half  of  a  spreading  table. 

The  work  assignments  in  a  plan  are  to  be  performed  in  the  order  in  which 
they  appear.  Associated  with  each  work  assignment  is  a  status  of  completion — 
unsiarted,  »n  progress,  suspended,  and  completed.  Initially  all  work  assignments 
are  marked  unsiarted.  Given  a  plan  P,  a  set  of  operators  O.  a  set  of  materials 
M,  and  a  set  of  equipment  S,  do  the  following  until  ail  work  assignments  are 
completed; 

^Iw  is  unfortunate  that  we  use  two  classes  with  very  similar  names.  Model  and  Models.  Th 
former  is  defined  by  the  Model/View/ControUerframework.  The  latter  is  the  correspondins 
DEVS  entity.  It  is  interesting  that  Zeigler  uses  the  same  name  (with  an  “s”)  for  this  class 
The  reader  is  urged  to  note  the  distinction  between  the  two  ntimes.  In  general,  we  will  us.’ 
the  term  model  to  refer  to  DEVS  entities  unless  otherwise  noted 

^Our  current  simulation  does  not  take  advantage  of  this  facility  because  it  complicates  the 
routing  of  operators  to  workstations. 
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Model 
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Dispatcher 
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CuttingMachine 
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BITECutter 
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Figure  3.2:  CdP  application  classes  (boldfaced). 
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For  each  operator  o  in  O  that  is  available  at  the  current  lime, 
associate  o  with  the  next  work  assignment  that  is  not  completed  and 
that  entails  o. 

For  each  material  m  in  .id,  dissociate  it  with  the  next  work  .as¬ 
signment  that  is  not  completed  and  that  entails  the  use  of  rii. 

For  each  work  assignment  w  that  is  unstarlred  or  suspended, 
with  which  sufficient  materials  and  operators  are  associated,  and 
for  which  the  required  workstation  is  available,  mark  if  as  being  in 
progress. 

If  the  operator  must  leave  the  workstation  before  the  task  is 
completed,  then  mark  the  task  as  suspended  and  return  the  operator 
to  O. 

If  a  task  is  completed,  then  mark  the  work  assignment  for  it 
as  completed  and  return  the  operator  to  (3and  any  unconsumed 
materials  to  M. 

Under  this  discipline,  each  operator  extracts  the  tasks  on  which  he  is  sched¬ 
uled  to  work  and  does  them  in  order,  realizing  that  some  tasks  might  be  com¬ 
pleted  while  he  is  off-duty  or  on  break.  Similarly,  materials  are  moved  around 
the  cutting  room  from  equipment  to  equipment,  depending  on  where  that  ma¬ 
terial  is  next  to  be  used.  The  appearance  of  various  resources— operators  and 
materials  and  equipment — in  the  plan  place  a  partial  ordering  on  work  assign¬ 
ments.  This  algorithm  preserves  that  ordering,  except  that  in  the  case  in  winch 
alternative  operators  0i  and  02)  are  specified  for  a  given  work  assignment  w.  and 
Oi  starts  work  on  the  task,  then  Oj  (j  ^  i)  can  start  work  on  a  task  appearing 
subsequently  in  the  plan,  later  to  return  to  complete  w. 

Some  tasks  require  the  output  of  a  prior  task  as  materials — for  example, 
cutting  tasks  generally  depend  upon  the  completion  of  spreading  tasks.  We 
represent  the  result  of  tasks  by  itckets  that  are  defined  in  work  assignments.  A 
ticket  may  appear  as  a  required  resource  in  a  task.  The  relation  between  ticket 
definition  and  ticket  use  also  creates  a  partial  ordering  on  tasks  that  must  be 
followed  in  carrying  out  a  plan. 

As  an  example,  consider  a  portion  of  a  plan  involving  three  operators,  three 
rolls  of  fabric,  and  two  spreading  tables; 
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then  4  layers  of  fabric  C. 

Table  1 
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Spread  10  layers  of  fabric  B. 

MJ 
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iH 

Table  2 
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Spread  6  layers  of  fabric  A. 

rm 

Louie 
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E  I 
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■ 

1 

Cut  [T]. 

m 

Dewey 

1 

B  ! 

■ 

Table  1 

1 

The  equipment  column  shows  a  workstation  as  a  shaded  portion  of  the  wlioie. 
We  designate  and  represent  a  workstation  internally  just  that  way.  A  ticket 
is  not  required  if  the  result  is  not  of  interest,  though  in  this  case  we  need  to 
process  the  result  of  each  task. 

Our  current  design  includes  four  tasks,  each  of  these  is  represented  by  a 
subclass  of  the  abstract  class  Task. 

•  Spreading — expressed  as,  “Spread  {  rolJj,  rollo,  ....  roll„}  following  tern- 
piate  T,"  where  the  template  specifies  how  the  spread  is  to  be  constructed 
and  the  fabric  rolls  satisfy  the  requirements  for  fabric  specified  in  the  tem¬ 
plate.  The  product  of  this  task  is  a  spread, 

•  Cutting — expressed  in  terms,  of  ’’Cut  spread,"  where  the  spread  is  an 
instance  of  Spread  or  a  ticket  that  represents  a  spread  product  of  some 
task.  The  product  of  this  task  is  a  set  of  stacks. 

•  Moving — expressed  in  terms  of,  “Move  object  to  workstation."  where  the 
object  is  any  material  (including  a  ticket)  and  workstation  designates  a 
workstation,  usually  one  at  the  same  equipment.  This  task  represents  an 
operation  such  as  sliding  a  spread  from  one  end  of  a  table  to  the  other 
or  positioning  a  cutter  at  the  end  of  one  spreading  table  to  the  end  of 
another. 

•  Bundling — expressed  as,  “Bundle  set  of  stacks,"  where  the  set  of  slacks  is 
an  instance  of  StackSet  or  a  ticket  that  represents  a  set  of  stacks  produced 
as  a  result  of  some  task. 
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A  task  must  be  able  to  compute  the  time  needd  to  complete  it  by  the 
operators  at  the  workstation.  A  task  also  tracks  its  ■'.mipleiioa  .status  as  a 
fraction  of  the  whole.  This  fraction — represented  as  a  percent — is  determined 
by  the  operator  and  the  materials  that  contributed  to  the  level  of  completion  .so 
far.  Thus,  a  task  that  is  half-completed  by  one  operator  in  an  hour  will  require 
two  hours  to  complete  by  another  operator  who  works  at  half  the  efficiency  at 
the  task  as  the  first  operator. 

3.2.2  Cutting  Rooms 

A  cutting  room  model  is  a  digraph  model  comprising  a  model  for  each  piece  of 
equipment  and  three  special  models: 

•  A  Break  Area  in  which  each  operator  resource  resides  when  it  is  off-duty — 
that  is,  on  break  or  not  at  work.  However,  an  operator  might  be  idle,  but 
by  a  piece  of  equipment  instead  of  in  the  break  area  because  an  on-duty 
operator  waits  by  the  equipment  containing  the  workstation  at  which  his 
next  task  is  to  start.  (The  algorithm  we  use  was  described  in  Section  j 
All  operators  are  in  the  break  area  when  a  simulation  run  starts. 

•  A  Drop  Area  in  which  each  material  resource  resides  when  it  is  not  required 
for  a  task.  All  resources  are  in  the  drop  c.r.ea  when  a  simulation  run  starts, 

•  A  Planner  that  holds  the  plan  contrc’l!’'.'.'  the  simulation.  For  historical 
reasons,  this  component  is  called  “Osc.ir"  and  roughly  corresponds  to 
the  cutting  room  manager.  This  comi  Mnent  disseminates  the  plan  for 
performing  the  various  cutting  room  tasks  to  other  simulation  components 
and  collects  simulation  results. 

This  organization  is  illustrated  in  Figure  3.3. 

CuttingRoom  is  a  subclass  of  Room,  whi-  !)  is  an  abstract  digraph  model 
class.  A  CuttingRoom  instance  contains  equipment  specified  at  the  time  of 
instance  creation  and  the  three  special  models  described  above,  Oscar  is  an 
instance  of  a  class  Planner  that  has  an  output  port  #pl3ni  connecting  to  the 
#plan  port  of  the  break  room,  the  drop  area,  and  each  equipment  model  (see 
Section  3.2.3).  The  plan  is  distributed  to  all  other  component  models  of  a  cutting 
room  via  these  connections.  A  planner  has  an  output  port  #result  through  which 
statistics  about  the  plan  are  produced  when  all  work  assignments  in  the  plan  are 
completed.  The  plan  held  by  a  planner  is  sent  over  each  #plan,',  i  =  1,2, .,  .n. 
where  n  is  the  number  of  other  models  in  the  cutting  room  (equipment,  drop 
area,  and  break  area),  when  a  plan  is  received  on  its  input  port  #start.  Statistics 
about  the  plan  are  computed  based  on  inputs  on  its  #done  input  port.  These 
inputs  are  instances  of  class  WorkAssignmentStatistics  that  provide  information 
about  the  start  and  end  times  of  the  task  it  includes. 

The  drop  area  and  the  break  area  in  a  cutting  room  are  instances  of  class 
Dispatcher.  A  dispatcher  is  an  atomic  model  that  manages  a  pool  of  resources. 


53 


Figure  3.3:  Cutting  room 
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dispatching  a  resource  to  another  model  in  accordance  with  some  plan.  A 
dispatcher  has  two  input  ports,  #plan  and  #in,  and  n  output  ports;  #outi, 
#out2,  #out„.  Port  #plan  is  an  input  port  on  which  a  plan  is  to  be  received 
that  drives  the  routing  of  resources  to  and  from  the  dispatcher.  Resources  arrive 
on  port  #in  and  are  dispatched  to  other  models  on  an  #outi  port. 

Each  output  port  is  assumed  to  be  routed  to  one  model.  The  association 
between  model  and  output  port  is  stored  in  a  dictionary  (mappingDictionary) 
and  is  established  at  instance  creation  using  the  models  provided.  For  example, 
if  the  models  are  mi  and  m2,  then  an  association  between  #outl  and  m;  and 
between  9i6out2  and  m2  is  made.  When  a  resource  arrives  on  #in.  and  the 
plan  reflects  that  the  resource  should  be  routed  next  to  mi ,  then  the  resource 
is  output  on  #outl  based  on  the  dictionary  association  of  mi  and  #outi.  A 
CuttingRoom  instance  ensures  that  connections  are  correct. 

Every  resource  in  a  dispatcher  must  be  able  to  answer  the  message  whereNext: 
aPlan,  providing  the  next  work  assignment  in  which  the  receiver  is  to  be  used. 
An  answer  of  nil  designates  that  the  resource  has  no  more  uses  within  the  plan. 
No  resource  is  dispatched  until  it  is  available  for  use — for  example,  an  operator 
who  is  off-duty 

At  the  start  of  a  simulation,  all  operator  resources  are  placed  in  the  break 
area  and  all  material  resources  are  placed  in  the  drop  area.  Each  dispatcher 
instance  sends  resources  to  the  equipment  model  containing  the  workstation  at 
which  that  resource  is  first  used,  based  on  its  reply  to  whereNext:  aPlan.  When  a 
model  no  longer  wants  a  resource,  it  routes  the  resource  back  to  the  appropriate 
dispatcher. 

3.2.3  Equipment  and  Workstations 

Instances  of  class  Equipment — or  more  properly,  instances  of  its  various  subclasses 
model  pieces  of  machinery.  An  equipment  model  has  three  input  ports: 

•  #plan  on  which  a  plan  arrives  before  any  other  inputs  are  accepted 

•  ^optrln  on  which  operators  arrive 

•  #matlln  on  which  operators  arrive 
and  four  output  ports: 

•  #done  on  which  statistics  about  a  completed  work  assignment  is  emitted 

•  ^product  on  which  a  completed  product  is  emitted 

•  9|toptr0ut  on  which  operators  are  emitted 

•  #matlOit  on  which  materials  are  emitted 
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Equipment  has  behavior  such  that  if  it  has  a  -.vork  assignment  in  the  plan 
that  is  still  not  completed,  and  sufficient  resources  and  operators  are  available 
at  the  equipment  to  perform  the  work  assignment,  and  the  workstation  for  the 
assignment  is  available,  then  work  on  the  task  is  begun.  Upon  completion  of  a 
work  assignment,  statistics  are  emitted  on  port  #done,  the  product  is  emitted 
on  ^product,  the  collection  of  operators  who  performed  the  task  are  emitted  on 
#optrOut,  and  the  collection  of  materials — what’s  left  of  them — is  emitted  on 
#matlOut.  It  is  sometimes  the  case  that  an  operator  at  a  workstation,  or  an 
operator  in  the  wait  area,  goes  off-duty.  In  that  case,  the  operator  is  emitted 
on  #optrOut  and  any  t2tsk  on  which  he  was  working  is  either  suspended  or  is 
resumed  by  another  on-duty  operator  in  the  wait  area. 

When  a  resource  arrives  at  equipment,  it  is  put  in  the  wait  area  and  then  a 
check  is  made  to  see  if  an  uncompleted  work  assignment  in  the  local  plan — those 
work  assignments  for  this  equipment— can  be  started  based  on  the  presence  of 
all  required  resources  in  the  wait  area  and  the  availability  of  the  workstation 
specified®.  When  a  work  assignment  is  started,  eligible  operators  in  the  wait 
area  not  selected  for  the  task  are  emitted  on  port  #optrOut  (where  they  are 
routed  to  the  dispatcher). 

Every  piece  of  equipment  comprises  a  set  of  workstations.  For  this  class, 
only  one  workstation  can  be  active  at  a  time.  (See  subclasses  for  equipment 
that  can  support  multiple  active  workstations.) 

Each  piece  of  equipment  has  a  wait  area  at  which  idle  operators  and  materials 
wait  for  the  start  of  a  task  specified  in  a  work  assignment.  The  wait  area  is 
represented  by  instance  variables  waitingOperators  and  waitingMaterials. 

Equipment  has  the  phases  and  transitions  shown  in  Figure  3.5. 

3.2.4  Resources 

Resources  comprise  the  operators  and  materials  to  be  allocated  to  a  set  of  work 
assignments.  Class  Resource  is  an  abstract  class  that  contains  Operator  and 
Material  as  subclasses.  Resource  establishes  common  state  and  protocols  to 
determine: 

•  job — the  work  assignment  in  which  this  resource  is  participating  (if  any) 

•  equtpmeni — the  equipment  at  which  this  resource  is  stationed  (if  any) 

•  status — the  current  status  of  this  instance;  #busy  or  ^idle 

•  image — a  pixmap  that  provides  a  picture  of  this  resource  in  its  current 
state. 

The  images  are  stored  in  a  dictionary  and  retrieved  using  the  current  status  as 
a  key. 

®The  cTirrent  implementation  insists  that  work  assignments  be  started  in  their  order  in  the 
plan.  However,  this  is  not  necessary  as  long  as  the  ptirtied  ordering  is  preserved.  This  was 
just  an  implementation  convenience 
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Operators 

Operators  are  resources  that  model  the  behavior  of  workstation  operators.  An 
operator  is  not  a  DEVS  entity,  but  an  object  that  is  passed  between  models 
and  affects  their  states.  Operators  are  unusual  objects  in  this  system  in  the 
sense  that  they  are  autonomous,  acting  based  on  the  circumstances  in  which 
they  find  themselves  and  changing  state  independently  of  where  they  are  based 
on  simulation  lime — -for  example,  quitting  work  for  the  day  when  a  shift  ends. 

We  have  addressed  this  autonomy  by  making  operators  passive  components 
and  having  all  models  that  base  their  states  on  operators — equipment  mod¬ 
els  and  dispatcher  models — be  aware  of  operator  state.  For  example,  a  dis¬ 
patcher  model  will  consult  with  each  operator  object  it  wishes  to  dispatch, 
asking  whether  it  is  available  at  the  current  simulation  time  and  dispatching  it 
if  it  is,  or  baising  an  internal  transition  on  the  time  at  which  it  becomes  available 
if  it  is  not.  In  short,  models  that  use  operator  resources  consult  the  operators 
as  part  of  their  transition  functions. 

As  a  passive  object,  each  operator  must  be  able  to  respond  to  two  messages: 

•  availableAfter:  aSimulationTime  to  which  the  receiver  answers  the  duration 
until  it  is  available  after  the  time  indicated 

•  availableAt:  aSimulationTime  to  which  the  receiver  answers  whether  or  not 
it  is  available  at  the  time  indicated 

Thus,  an  operator  instance  need  only  know  its  work  schedule  to  respond  to  these 
messages. 

Operator  instances  have  other  operations  as  well,  such  as  being  able  to  an¬ 
swer  its  efficiency  at  a  given  workstation  and  the  various  tasks  it  is  asked  to 
perform. 

Materials 

Materials  are  resources  that  are  consumed  or  produced  in  a  cutting  room — for 
example  rolls  of  fabric,  markers,  spreads,  stacks,  and  so  on.  The  class  Material 
serves  as  an  abstract  class  and  all  materials  are  instances  of  its  subclasses. 
Unlike  operators,  materials  are  passive,  manipulated  by  the  models. 

Certain  equipment  resources  must  be  considered  materials — namely,  hand¬ 
held  equipment  such  cis  rotary  shears.  These  items  do  not  function  in  the  same 
way  as  other  equipment.  For  one  thing,  they  do  not  support  workstations.  For 
another,  they  can  be  moved  around  just  as  materials. 

3.3  User  Interface 

The  user  interface  classes  provide  support  for  windows  that  display  a  simulation 
run  in  progress  and  buttons  for  controlling  a  simulation  run.  The  interface  is 


58 


Object 

VisualCorr^onent 
VisualPart 
Depend  entPart 
View 

CuttingRooinSimulationView 
DEVSRunView 
DEVS  View 
ModelsView 
AtomicModelView 
DispatcherView 
Equipment  View 
Planner  View 

SimpleProcessorModelView 
TransducerModelsView 
Processors  View 
CoordinatorView 
RootCoordinatorView 
SimulatorsView 
SimulationRunView 

Figure  3.6:  User  interface  classes. 


based  on  the  Model/ View/Controllerframework.  The  simulation  model  is  a 
subclass  of  Model.  The  simulation  window  contains  instances  of  classes  View 
and  Controller. 

The  user  interface  classes  comprise  views  of  some  of  the  DEVS  and  appli¬ 
cation  classes.  AH  of  the  user  interface  classes  are  subclasses  of  the  class  View 
defined  by  Model/ View/Controller.  The  hierarchy  is  shown  in  Figure  3  6. 

3.3.1  Simulation  Run  Views 

The  window  placed  on  a  screen  to  show  a  simulation  run  is  an  instance  of 
SimulationRunView.  An  instance  is  created  with  the  message  openCn:  which 
takes  an  instance  of  a  root  coordinator  as  its  parameter' . 

A  simulation  run  view  creates  a  window  on  the  screen  containing  a  view  for 
each  atomic  model  in  the  tree  connected  to  the  root  coordinator.  The  window 
also  displays  a  pane  for  the  root  coordinator  that  displays  the  simulation  time 
and  other  simulation  run  information. 

^In  the  current  design,  a  scenario  is  a  root  coordinator,  but  a  scenario  .dass  should  have 
been  defined! 
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A  suiiuiation  run  view  provides  four  butious  for  conirolluig  a  bimulation 
Restart  sends  a  reset  message  to  the  root  coordinator 
Go  sends  a  message  go  to  the  root  coordinator 
Pause  sends  a  message  pause  to  the  root  coordinator 
Step  sends  a  message  step  to  the  root  coordinator 

The  meanings  of  these  buttons  are  described  in  the  User's  Manual  Ihese 
buttons  can  be  used  at  any  time,  though  the  Restart  button  generally  can  be 
used  only  once  at  the  beginning  of  a  simulation  run  unles^s  all  of  the  mudei!. 
and  processors  involved  have  stored  their  start  statc-s  to  permit  resetting  In 
addition,  all  consumed  materials  must  be  re-created,  so  restarting  is  a  nontnviai 
operation,  in  general.  VVe  have  included  the  button  in  our  design  primarily  i.j 
help  us  with  debugging. 

The  placement  of  the  various  views  m  the  window  is  hard-coded  for  our  pro¬ 
totype.  An  interface  should  be  defined  for  more  explicit  layout  of  the  variou.s 
views,  perhaps  with  an  interactive  component.  This  capability  entails  more  pro 
gramnung  than  we  could  address  within  time  constraints.  Ideally,  any  model's 
view  could  be  placed  anywhere  within  the  window  Similarly,  coupled  mod¬ 
els  could  have  their  component  models  arranged  arhitrarily  wuhm  the  model 
boundaries.  The  Smalltalk  class  library  supports  such  operations,  but  we  were 
unable  to  take  advantage  of  this  because  it  took  us  a  long  time  just  to  figure 
out  how  to  get  the  rudimentary  set  of  views  installed  in  a  window'’ 

The  various  views  installed  in  the  window  display  bitmaps  intended  to  por¬ 
tray  the  status  of  the  model.  Consequently,  every  DEV'S  entity  must  be  able  to 
provide  an  instance  of  P/xmap  (or  one  of  its  subclasses)  in  response  to  a  state 
message. 

3.3.2  Models  Views 

Class  ModelsView  provides  an  abstract  class  from  which  all  other  model  view 
classes  inherit.  This  class  provides  a  pixmap  comprising  a  rectangle  labeled  with 
the  name  of  the  model  provided  upon  instance  creation.  The  size  of  the  rectangle 
IS  determine  by  the  messages  defaultWidth  and  defaultHeight.  A  subclass  can 
override  these  methods  to  change  the  size  of  the  pixmap. 

Each  model  view  has  a  rectangle  in  which  subclasses  can  place  additional 
information.  This  rectangle  is  accessed  by  subclasses  using  the  message  inse- 
tRectangle.  The  origin  and  corner  of  the  inset  rectangle  can  be  used  to  determine 
where  subclasses  can  put  additional  slate  information. 

A  subclass  of  ModelsV/iew  is  defined  for  atomic  models  and  for  digraph  mod¬ 
els. 

®In  fact,  we  were  vinable  to  eliminate  a  bug  in  our  implementation  with  respect  to  the 
buttons.  For  some  reason,  the  window  must  be  scrolled  to  the  top  before  any  button  pres.s 
will  take  effect. 
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Atomic  Model  Views 

Instances  of  the  class  AtomicModelView  display  the  current  values  oi  t,  sigma 
and  X  for  the  model. 

3.3.3  Processors  Views 

3.3.4  Synchronization  of  Views  and  Simulation  Runs 

A  root  coordinator  and  a  view  must  synchronize  their  operations  When  receiv¬ 
ing  a  go  message,  a  root  coordinator  spawns  a  process  to  perform  a  simulation 
run.  The  view  controls  this  process  by  sending  messagtia  to  the  root  coordinator 
These  messages  are: 

•  reset — restart  the  simulation 

•  pause — interrupt  the  simulation  on  the  next  iteration  of  the  loop  that 
advances  global  time 

•  step — run  an  interrupted  simulation  one  time  step 

•  resume — continue  running  an  interrupted  simulation 

These  messages  control  the  actions  taken  by  the  simulation  run  process  and 
are  translated  by  the  root  coordinator  into  actions  on  its  current  mode  that 
reflects  one  of  five  states  for  a  run: 

•  id/e— not  yet  initialized,  or  run  completed 

•  ready— initialized,  but  not  yet  started 

•  running — run  in  progress 

•  suspended — run  suspended 

•  stepping — running  a  single  step 

The  mode  is  set  using  accessors  mode  and  mode:  which  implement  critical 
regions  using  a  semaphore  modeSemaphore  to  ensure  exclusive  access.  An  ad¬ 
ditional  semaphore,  controlSemaphore,  is  used  to  suspend  the  simulation  run 
process  when  the  mode  is  not  running 

This  design  using  a  separate  process  and  semaphores  was  necessary  to  get 
the  interactive  behavior  that  we  wanted  in  the  Objectworks  environment.  The 
Model/View/Controllerframework  is  designed  based  on  a  transaction-oriented 
model  that  cycles  between  user-initiated  stimulus  and  model  response.  Our 
system  requires  that  the  system  be  able  to  operate — that  is,  run  a  simulation — 
freely  on  its  own,  providing  the  opportunity  for  user  intervention. 
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3.4  Debugging  Support 

The  systetii  contains  code  to  support  debui^uig  iii  both  the  form  of  lo^^gstig 
message  traffic  between  procttssors  and  models,  and  m  the  form  of  an  iiiieractivr 
user  interface. 

3.4.1  Logging  Messages 

Messages  sent  and  received  by  the  entities  in  the  system  can  be  logged  !>>  s<'ndiiig 
the  name  of  an  open  write  stream  to  the  class  Entities  (or  any  of  ns  Mibcias-v's) 
via  the  message  logStream:.  The  output  is  te.xt  written  to  the  .stre.im.  oni* 
message  per  line.  For  example,  the  following  sequence  will  log  mes.sage.s  to  !h<- 
file  ioo.log: 

Processc.s  logStream  foo  log'  asFilename  writeSlream 
The  file  can  be  closed  by  sending  nil  or  another  stream  object  as  the  p.ir.an!<  t<*r 
Processors  logStream  nil 

Logging  output  is  also  available  o-  UTgX  format  by  .sliding  true  as  the 
parameter  to  a  teXFormat:  message; 

Processor-  teXFormat:  true. 

The  format  c..'i  be  cancelled  by  sending  false  as  the  parameter.  The  output 
makes  use  of  a  number  of  macros  that  can  be  defined  for  convenience.  These 
macros  fall  into  two  general  categories; 

I,  Central  DEVS  components.  These  are  the  macros  that  pertaui  to  mi-s- 
sages  a;;  i  their  contents — messages  sent  and  received,  ports,  times,  .and 
content.' 


\logMessage{  text } 

\sendingMessage{  target  entity }  { confenf} 
\logTime{fjrne} 

\receive<lMessage{  consent} 

\outputEh{t)a/ue} 

\timeAdvanceEh{d«rorion  to  next  transition} 
\txtTransFn{  elapsed  fme}{inpul  value] 
\intTr3nsFn{ neui  pAase} 

\port{  model  name]  (port  symiol] 

\Content  (pur/ }  {  value } 
\DEVSMessage{<ype}{orijina<or}{  (im« } 
\DEVSIOMessage{  type}}  originator)  { time }  { t  oitie } 
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2.  Simuiaiwn-sptcific  components  I’hes**  are  macros  whose  naim-s  arc  lakrii 
from  the  names  of  the  models  anti  processors  tn  a  simulaiion  I  he  iiiacro 
name  corresponds  to  the  name  of  an  entity  -  for  example,  a  mtidr-i  name.i 
M  is  represented  by  the  macro  \M  and  its  simulator  S  M  by  the  macro 
\SM.  (Any  non-alphabetic  character  is  removed  from  the  name  to  satisfy 
LkTjcXnammg  conventions.)  Each  of  th<?se  macros  has  one  argument  tiie 
operation  being  logged  by  the  component  associated  with  the  name  for 
example,  \SM|\receivedMessage(  }} 

The  macros  below  were  used  to  produce  the  output  in  Section  2  2  3 


\neBenviron]n«nt{CLIP}{ 

\b«gin<tabbing> 

xxxxzx\=xixxxx\-xiixxx\-xxxxxx\=xxxzxxxxxxxx\=xx*xxx  \Xill 

H 

\and{tabbing> 

} 

\neHcomBiajnd{\RC}[l]{#l  \\} 

\nescoiaaand{\CEFP>Cl]'{\>  #1  \\} 

\ne»comffland{\SP}Cl]{\>  \>  •!  W) 

\neBcoBUBand{\CEF}Cl]{\>  \>  \>  #l  \\} 

\n*Bcommand{\SGEHR}Cl3f\>  \>  \>  \>  •!  \\} 
\neBCoauBand{\STRAKSD}[l]{\>  \>  \>  \>  \>  #1  \\} 

\ne8Comniand{\PR0CESS0R>Cl]{\>  \>  <\«b  #1>  W} 
\neBcoinmand{\GElfR}Cl]{\>  \>  \>  \>  {Nem  *1}  \\} 
\neBCOBmand{\TRAllSD} [l] {\>  \>  \>  \>  \>  {\ob  #1}  \\} 

\neBComBaiid{\logM«88age}Cl3{#l} 

\n«BConiBand'{\s6ndingK«88ag«} [2]  {s«nd ;  92} 
\neBCOBfflaiid<MogTiB«}[l]-C\rul«<06B>-{4ex>{\bl  Time:  #!>} 
\neBcommand{\receiT6dHessage}Cl] freev :  #1} 
\neBcoBBand{\outputEh>[l]<output?()  $\rightarroB$  #1} 
\neBCOBBand<\tiB8AdvanceEh>[l3{ta7()  $\rightarroB$  #1} 
\neBC0BBaiid{\extTran3Fn}C2]-(8xt  tran8  ln(#l.  #2)} 
\neBC0BBaiid<\intTransFn}Cl3{int  trams  ln()  $\rightarroB$  #1} 
\neBcoBBand{\port} [23  f#! . 92} 

NneBCOBBand-CXContent}  [23  {#2} 

\n«BC0BBauid{\DEVSH«8sag«} [33 f$*{#l}$\fbox{#3>} 
\naBCOBBand<\DEVSI0Messag«}[43-($"{#l}$\tbox{#3;  #4» 

The  output  of  the  simulation  run  is  formatted  in  a  CLIP  environment.  Note  t  hai 
the  simulation  contains  a  processor  model  P  and  we  had  to  rename  the  macro 
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\P  to  \PR0CESS0R  to  avoid  the  predefined  macro  for  the  paragrapii  ^>  inb»d  t  ^ ! 
Alternatively,  we  could  have  just  renewed  command  \P 

3.4.2  Debugging  Views 

in  addition  to  logging  messages  to  a  file,  we  have  tinplemented  views  for  inter 
actively  monitoring  the  activity  of  DEV'S  entities  These  views  are  sub<  iasv-s 
of  View  and  one  class  exists  for  each  kind  of  DEVS  processor 

Object 

VlsualComponent 

VisualPart 

OependentPart 

View 

Processors  View 
Coordinator  View 
RootCoordinatorView 
SimulatorsViow 

Each  of  these  views  display  the  instance  variables  of  their  corresponding  DEV'S 
entities — for  example,  a  SimuiatorsView  instance  displays  sigma,  elapsed  time  in 
the  current  state,  the  most  recently  received  x  message,  and  the  most  recently 
sent  y  for  its  model. 

These  views  are  installed  within  other  views  and  each  is  attached  to  the 
appropriate  model  upon  creation  via  the  new  aModel  mi'ssage  sent  to  the  cl;v.s.s 
For  convenience,  each  DEVS  class  responds  to  the  message  view  with  liie  claiss 
appropriate  for  itself — for  example,  an  atomic  model  responds  with  ilie  Simuia¬ 
torsView  class. 

These  views  are  most  useful  for  debugging  and  are  currently  a  part  of  cla-s.s 
SimulationRunView  instances  because  we  have  been  debugging  At  some  point, 
these  views  should  be  removed.  It  is  more  appropriate  to  have  separate  win¬ 
dows  providing  application  and  debugging  views  of  a  simulation  run.  That 
design  occurred  to  us  late  and  we  were  unable  to  make  the  changes  required 
(straightforward  and  simple  as  they  are)  within  our  time  constraints 

3.5  Testing  Support 

Test  cases  are  provided  in  some  class  comments,  generally  in  a  section  labeled 
Testing.  Some  classes  require  a  substantial  amount  of  setup — for  example,  com¬ 
plex  networks  of  objects— so  test  cases  are  not  provided  for  them. 

The  experimental  frame  example  used  by  Zeigler  to  describe  the  various 
aspects  of  DEVS  has  been  the  bcisis  for  our  testing  of  the  DEVS  components  of 
our  system.  This  model  hierarchy  is  embodied  in  the  classes  SimpleProcessor. 
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Generators,  and  Transducers  (see  Appendix  (').  We  did  noi  uiipU-ineiii  c!ass<'s  i,j 
explicitly  model  experimental  frames  (EF)  or  experimental  frames  connected  lu 
simple  processors.  Instead,  these  digraph  models  are  coaslriicied  expiiculy  tn 
a  code  sequence  found  in  file  aiapl«T«at.  This  code  parallels  the  construction 
used  by  Zeigler. 

Class  DEVSRunView  provides  a  window  for  a  run  of  this  model  hierarchy 
The  window  is  laid  out  with  a  column  of  views  on  processors  down  the  left  .■,ide 
of  the  window  and  a  column  of  views  of  models  down  the  right  Hie  proces-wr 
and  model  views  appearing  in  the  same  row  are  paired.  T'his  view  allows  one 
to  watch  the  message  traffic  between  processors  as  well  as  the  slate  changes  to 
the  atomic  models. 

To  run  this  test,  open  the  file  siispleTest  in  a  file  editor  window,  .select 
all  the  text,  and  select  do  it.  [The  text  of  this  file  is  given  in  .Appendix  (.' ] 
The  program  opens  a  window  containing  a  view  of  the  various  components  T 
the  model  and  execution  begins  after  the  selection  of  Restart  and  tfien  t!o 
The  statistics  collected  by  the  transducer  an  printed  to  the  iranscript  window 
These  results  should  match  the  following; 


The  arrived  list: 

’Job  S‘->60  Bi&utss 
’Job  0’->0  ainutss 
’Job  2 ’->20  ainutes 
’Job  4 ’->40  ainutes 
'Job  1’->10  ainutes 
’Job  3 ’->30  ainutes 
'Job  6 ’->60  minutes 
’Job  7 ’->70  minutes 
’Job  8 ’->80  ainutes 
’Job  9 '->90  minutes 
'Job  10 ’->100  minutes 

The  solved  list: 

'Job  0’ 

'Job  1’ 

'Job  2’ 

'Job  3' 

'Job  4’ 

'Job  5’ 

'Job  6’ 

'Job  7’ 

'Job  8’ 

'Job  9’ 

Avg.  turnaround  time:  5  minutes 

Throughput;  (1/10) 
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Appendix  A 

DEVS  Class  Specifications 


Specifications  for  DEVS  classes  are  provided  in  this  appendix.  These  cl;isses  an 
in  the  DEVS-Simulation  Category  in  the  image  st80-ClIP 
A  class  specification  follows  the  format: 


Superclass  subclass: 

Class 

-4  comment  about  ike  purpose  and  usage  of  the  class. 

instanceVariable 
inhentedlnstance  Variable 

instance  method  category 

newInstanceMethod 
inhentedlnstance  Method 
overriddeninsiance  Method 

class  method  category 

newClassMethod 
inhentedClass  Method 
ovemddenClass  Method 
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The  classes  in  the  DEVS  component  of  CflP  are  structured  ;is: 

Entities  [68] 

Models  [80] 

AtomicModel  [88] 

CoupledModels  [82] 

DigraphModcIs  [84] 

OynamicDigraphModels  [86] 

Processors  [69] 

Coordinator  [73] 

DynamicCoordinator  [75] 

RootCoordinator  [77] 

Simulators  [71] 

The  number  in  brackets  following  each  class  name  is  the  page  number  on  which 
the  specification  starts. 
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Model  subclass: 


Entities 
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Entities  subclass; 


Processors 


Abstract  class  for  a  DEVS  processor  (see  Z'-tgler  Sec  't  5  Ji  This  cTi'is  p’-ond'-^ 
protocols  for  linking  models  in  a  hierarchy  and  tracing  a  simulation  run  fracing 
IS  enabled  if  traceStream  has  a  value  other  than  ml. 

.Vote  that  we  use  'restart'  rather  than  initialiie '  for  model  initialication  il'i 
use  'initialize'  in  the  conventional  way  to  initialize  an  irtslance,  rr.siurt '  is 
to  reset  an  instance  for  another  simulation  run 

My  subclasses  are: 

RootCoordinator 
Coordinator 
Simulators 

Instance  vai-iables: 

devsComponent  <Models> 

child  Processors  <Sel> 

timeOfLastEvent  <StmulattonTime> 
timeOfN  extEvent  <SimulationTime> 

laslSentMessage  <String> 

lastReceivedMessage  <Stnng> 

name 
parent 

devsComponent 
childProcessors 
timeOfLastEvent 
timeOfNextEvent 
Icist  Received  Message 

lastSentMessage _ 

accessing  childProcessors 

last  Received  Messag** 
lastSentMessage 
processorTree 
proccssorTreeLeaves 
timeOfLastEvent 
timeOfNextEvent 


—  my  model 

—  my  direct  Processors  cia.ts 
descendents 

—  the  time  of  the  last  event 

—  the  time  of  the  next  event 

—  the  last  message  to  be  sent 

— the  last  message  to  be  received 
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DEVS 

displaying 

initialize-release 

printing 

private-accessing 


private-logging 

views 


devsComponent 
de  vsCorn  pori  en  i 
I  inkTo  Parent; 

restartAl; 

state 

vtsaalCovipunent 

intttalice 

pnntOn: 

pnntStnng 

child: 

lastReceivedMessage: 

lastSent  Message: 

parent: 

processors 

tirneOfLaslEverii 

limeOfNextEvenl; 

log; 

logReceipt: 

logSend:to; 

logTime: 

view 


instance  creation  1st 

new 

new: 

logging  access  isLogging 

logSirtam: 

leXFormai: 
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Processors  subchiss: 

Simulators 


,-i  Simulator  controls  an  atomic 
Instance  variables: 

None. 

model  (see  Zetgler  section  and  section  4-  ^  ' 

name 

parent 

devsComponent 
child  Processors 
timeOfLastEvent 
timeOfN  exiEvent 
lastReceivedM  essage 
lastSentMessage 

accessing 

processorTree  Leaves 

DEVS 

restart  At: 

starMessage; 

xMessage: 

displaying 

state 

vtsualComponent 

initialize*  release 

initialize 

printing 

pnntOn: 

pnntStnng 

private- accessing 

child: 

lastReceivedM essage: 

lastSentMessage: 

parent: 

processors 

timeOfLastEvent: 

UmeOfNeit  Event: 

private- logging 

log: 

logReceipt: 

logSend:to: 

logTime: 

protected-accessing 

child; 

Views 


processors 

view 


instancu  creation  .'i< 

new 

new. 

logging  access  is  Logging 

logStream 
te  X  format : 
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Proct^ors  subcUuss 

Coordinator 


.-I  coordinator  a  processor  for  j  coupled  rnodei 
Instance  variables: 

starChdd  <Processor>  — the  immtricul  child  the  ntii 

one  to  get  a  mess'^ge 

waitList  <Ordered('ollection>-  processor^  uaitnig  fur  mes¬ 

sages  fUot  used  ur  are 
tng  seguenttal  ern  ult(  ri  m-  .-.•liy 
starChild  would  i  vei  be  sn  this 
list! 

tNChildren  <SortedCotlecUon>  —a  list  of  my  children  urdeted 

by  /inir  of  the  tu  rt 

event  Actually,  a  list  of  done 
messages 


Note:  When  a  coupled  model  is  created,  then  its  children  s  processors  are  linked 
as  a  tree,  so  there  's  no  need  to  override  method  'hnkToParent  in  this  class 


name 

parent 

devsComponcnt 
chtldProcessors 
timeOfiastEvenl 
time  Of  Next  Event 
last  Received  Message 
lasiSentMessage 
StarChild 
waitList 

tNChildren _ 

accessing  processors 

StarChild 

tNChildren 

DEVS  restart  At: 

star  Message 
X  Message: 
yMessage: 

displaying  state 

vtsualComponeni 

initialize-release  initialize 
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printing  pnntOn: 

pnntStnng 

private  nextGuy 

siarChild: 

private-accessing  child: 

lastReceivedMessage 

laslSentMessage: 

parent- 

processors 

timeOf Last  Event 

timeOfNextEvent 

private- logging  log: 

logHeceipt: 

logSend:to: 

logTime: 

views  view 

instance  creation  1st 

new 

.  new: 

logging  access  tsLogging 

logSlre.am: 

teXFormat: 


Coordinator  subclass: 

DynarnicCoordinator 


4  dynamtc  coordinator  is  a  coordinator  that  supports  simulation  of  a  coupled 
mode!  that  changes  dynamically-tkat  is,  that  changes  its  component  models  as 
simulation  progresses. 

A  dynamtc  coordinator  adds  operations  to  add  and  remove  sub-models.  The 
methods  vi  this  class  update  the  processor  only.  It  is  the  sender  s  responsibility 
to  update  the  model  correspondingly. 

4n  added  component  cannot  become  the  imminent  child  and  a  removed  compo¬ 
nent  cannot  have  been  the  imminent  child.  An  easy  way  to  meet  these  restric¬ 
tions  IS  for  a  dynamic  digraph  model  to  contain  a  persistent  model  that  performs 
updates  during  an  internal  or  external  transition. 

A  dynamic  coordinator  is  our  own  invention.  Zeigler  defines  no  such  object. 
Note  that  this  implementation  is  incomplete. 

name 
parent 

devsCom;:  anent 
childProc-  ssors 
timeOf Las!  Event 
timeOf Next  Event 
lastReccirt  dMessage 
lasiSentM'  .ssage 
starChild 
waitList 
tNChildren 
access-  dy  namic 

accessing 
DEVS 


displaying 

initialize-rolease 

printing 


addChildModel: 

removeChild  Model: 
processors 

siarChild 

tNChildren 
restart  At: 

starMessage: 
xMessage: 
y  Mess  age: 
state 

visualComponent 

initialize 

printOn: 

pnntStnng 
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private 

private-accessing 


private- logging 

views 


neztGuy 

starChtld: 

cktld: 

last  Received  Message: 

lasiSenlMessage: 

parent: 

processors 

timeOf Last  Event: 

ttmeOf Next  Event: 

log: 

logReceipt: 

logSend.to: 

logTime: 

view 


instance  creation  1st 

new 

new: 

logging  access  isLoggtng 

logStream: 

teXFormat: 
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Processors  subclass; 


RootCoordinator 


4  root  coordinator  controls  a  simulation.  It  serves  as  the  root  of  a  hierarchy  of 
DEVS  models  and  contains  one  child,  either  a  coordinator  (coupled  model)  or  a 
simulator  (atomic  model). 

Method  ’linkTo Parent is  used  instead  of  'initialize'  described  by  Zeigler  p.  66. 
Instance  variables: 

clock  <StmulationTime>  — the  current  global  clock 

child  <Processors>  — the  single  child  processor- 

coordinator  or  simulator.  We 
use  this  for  convenience,  rather 
than  ’chtldProcessrs  first  ’ 

timeLimit  <SimulaiionTime>  — the  time  at  which  a  simulation 

run  IS  to  stop 

mode  <Symbol>  — the  current  mode: 

#idle  —  not  yet  run  or  completed 
^running  —  run  in  progress 
fjfsuspended —  run  suspended 
fjfstepping  —  running  a  single  step 

processes  <Set>  — the  set  of  processes  created. 

Each  run  requires  the  creation 
of  a  process.  This  process  is 
terminated  when  an  instance 
is  released,  usually  when  the 
window  IS  closed  via  method 
‘change Request 

modeSemaphore  <Semaphore>  — Used  for  mutually  exclusive  ac¬ 

cess  to  mode 

controlSemaphore  <Semaphore>  — Used  to  control  each  iteration 

of  a  run 
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name 

parent 

devsComponent 

chtld  Processors 

UmeOfLastEvent 

limeOfNextEveni 

lastReceivedMessage 

lastSeniMessage 

clock 

child 

startTime 

tirneLimit 

mode 

traceText 

runView 

processes 

modeSemaphore 

controlSemaphore 


accessing 

child 

clock 

clock: 

StartTime 

startTime: 

tirneLimit: 

changing 

changeRequest 

DEVS 

linkToParent: 
restart 
restart  At: 

restart  At.andRunFor 

simulate 

yMessage: 

displaying 

state 

initialize- release 

initialize 

operating 

release 

go 

pause 

reset 

resume 

run 

printing 

step 

printOn: 

printstring 
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private-accessing  child: 

lastReceivedM  essage: 
lastSeniM  essage : 
parent: 
processors 
timeOf Last  Event: 
ttmeOf Next  Event: 


private- logging  tog: 

logReceipi: 

logSend.to: 

logTime: 

private-synchronizing  mode 

mode; 

views  view 


instance  creation  hi 

new 

new: 

logging  access  tsLogging 


tog  Stream: 
teXFormat: 


Entities  subclass: 


Models 


Models  IS  ike  root  class  for  a  DEVS  model.  [Note  that  ’Model’  is  already  a  class 
in  the  library.] 

Class  variables: 

None. 

Instance  variables: 
processor 


tnport 

ouiport 

ptxmap 


<Proces$ors>  — The  processor  associated  with 

this  model  instance. 

<Collection>  — The  input  port  designations. 

<Colleciion>  — The  output  port  designations. 

<Pixmap>  — A  ptxmap  that  represents  the 

current  state. 


In  addition,  sigma  is  the  time  left  in  the  current  phase. 

Each  subclass  should  initialize  the  input  and  output  port  designations  for  each 
instance.  This  class  requires  protocols  for  'initialize  ’  and  ’restart  ’.  The  distinc¬ 
tion  ts; 

initialize  Initialize  those  components  of  the  instance  that  are 
fixed  at  creation,  normally  the  input  and  output 
port  names  and  perhaps  defaults  for  graphical  com¬ 
ponents.  Note:  a  method  ‘initP  ■^s'  is  required  for 
initializing  port  names. 

restart  Initialize  those  components  of  the  instance  that 
define  the  state  of  the  model  at  the  start  of  a 
simulation. 


name 

parent 

processor 

inport 

outport 

pixmap 

accessing  inport 

outport 

processor 

processor: 

DEVS  restart 

displaying  state 
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initialize-  release 

port  creation 
printing 

private 

private-accessing 

private-logging 

views 


extent: 

tntiialize 

initPorts 

} 

prtntOn: 

pnntSinng 

baseVisualComponent 

inport: 

outport; 

name: 

parent 

parent: 

ieXNamt 

tsLogging 

view 


instance  creation  new 

logging  access  tsLoggxng 

logSiream: 


teXFormai: 


Models  subclass: 

CoupledModeis 

A  coupled  model  is 
tion  (see  Zeigler  pp. 
Instance  variables: 

an  abstract  class  that  embodies  hierarchical  model  composi- 
■  59ff). 

children 

<Collectton> 

—  the  list  of  component  models 

receivers 

<Collection> 

—  associates  an  input  port  of  my 
model  with  my  children  who  are 
connected  to  it.  This  is  main¬ 
tained  by  my  subclasses. 

influencees 

<Colleciion> 

—  connections  between  compo¬ 
nent  output  po7~ts  and  input 
ports.  Each  component  is  a 
coupling. 

priorityList 

<  OrderedColleciton' 

> — used  to  break  ties  resulting  from 
two  children  having  the  same 
time  to  next  event.  The  first 
child  in  this  list  has  highest  pri¬ 
ority.  The  select  function  (p. 
56)  uses  this  list. 

name 


parent 

processor 

inport 

outpori 

pixmap 

receivers 

influencees 

priorityList _ 

getChildren 
getinfluencees: 
get  Receivers: 
influencees: 
priority  liISl. 
receivers; 
select; 

translate 
restart 


accessing 


DEVS 
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displaying 

state 

initialize- relea.«e 

extent: 

initialize 

imiPorts 

port  creation 
printing 

private 

pnntOn: 

pnntSinng 

base  VisualComponent 

inport: 

outport: 

private-ac  ces  sing 

name: 

parent 

parent: 

private-logging 

teXName 

isLogging 

views 

view 

instance  creation 

madtePair; 

■logging  access 

tsLogging 

logStream: 

teXFormai: 

CoupledModels  subclass; 

DigraphModels 


Digraph  models  are  coupled  models  containing  a  heterogeneous  mixture  of  chil¬ 
dren  and/or  non-regular  couplings  between  children  (see  Zeigler,  chapter  5). 
Instance  variables: 

compositionTree  <CompositionTree> — defines  the  component  models 
influence  Digraph  <  DirectedGraph>  — defines  which  children  influ¬ 

ence  others,  i.e.  whose  outputs 
affect  whose  inputs. 

selectFn  <BlockContezt>  — a  block  having  one  parame¬ 

ter.  an  ordered  collection  from 
which  it  answers  the  next  im¬ 
minent  child  to  be  selected.  If 
this  variable  is  nil.  then  prior¬ 
ity  List  IS  used. 

name 

parent 

processor 

inport 

outport 

pirmap 

receivers 

tnfluencees 

pnontyList 

compositionTree 

influenceDigraph 

selectFn 

accessing  getChildren 

geiinfluencees: 

getReceivers: 

influencees: 

pnontyList: 

receivers: 

select: 

translate 
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DEVS 


displaying 
initialize-  release 


port  creation 
printing 

private 


private-accessing 


private-logging 

views 


addCouple:port:coiuu'Cted'lV)  port: 

buildComposilionTree: 

compositionTree 

connect:  to: 

getChildren 

getlnfluencees: 

getReceivers: 

select: 

select  Fn: 

setExtInpCoup:connect:to: 
setExtOutCoup:connect:to: 
setIntCoupport.N'ame:  to:  port  Name: 
specifyChildren: 

translateimodel: 

state 

extent: 

tmttalize 

tnttPoris 

■pnntOn: 

pnntStnng 

base  VisuaiComponent 

xnport: 

outpori; 

name: 

parent 

parent: 

leXName 

tsLoggtng 

view 


instance  creation  new: 

logging  access  tsLoggxng 

logStrcam: 

tcXFormat: 
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Digraph.Modfls  subciaas 

DyiiaiiiicDigTaphModfls 


a  dynamic  digraph  model  ts  a  dynamic  model  in  uhtch  the  campone nt  Dti/Jcij 
can  be  created  and  de.itroyed  during  u  nmuiation  run  The  dyriamici  rtguitr 
close  cooperation  with  the  coordinator  attached  to  this  instance  uhidi  must  t-r 
an  instance  of  DynamicCoordinator 

Note  that  this  class  has  not  been  implemented 

name 
parent 
processor 
inport 
ouiport 
pirmap 
receivers 
influencees 
pnontyList 
compostiionTree 
influence  Digraph 

seleclF  n _ 

access-dynamic 


accessing 


adclChiUiMo.i.d 

addChilci.NJodelwiihfc^xtrrnaiinjjut- 

CouplingswithExternaiOutpui- 

Couplings  wiihInternaH  'ooplinKs 

gelChtldrrn 

geiinfiuencees: 

geiReceivers: 

influencees: 

pnoniyList: 

receivers  : 

select: 

translate 
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DEVS 


displaying 
initial  izc^release 


port  creation 
printing 

private 


private-accessing 


private-logging 

views 


addCouple : port  connected,  Tu  port: 

buildCompontttun  Tret: 

componttoriTree 

connect.io. 

geiChildrtn 

getlnfiuencees: 

getReceivers: 

select: 

selectfn: 

setEzlInpCi  upiconncct.tu: 
set  EztGutCoup:  connect:  to: 
setIntCoup:portSame:to  ports'  amt: 
specify  Children: 

translate  .model: 
state 

eztent: 

initialize 

initPorts 

printOn: 

puntSinng 

base  VisuatComponenl 

inport: 

outport: 

name: 

parent 

parent; 

ieXName 

isLogging 

view 


instance  creation  new: 

logging  access  isLogging 

iogStream: 

teXFormat: 


Models  subclass; 


AtornicModel 


.4n  tnsiance  of  class  AtornicModel  represents  a  specific  atomic  model.  Protocol 
provided  for  the  object  corresponds  to  the  DEVS  protocol  for  atomic  models. 
This  implementation  vanes  from  Zeigler’s  in  that  we  use  instance  variables  to 
hold  that  state  rather  than  a  single  variable  s. 


Instance  Variables: 

X 

<  Conteni> 

— external  input  causing  this 
event 

y 

<  Conteni> 

—  most  recently  generated  content 
for  output 

sigma 

<  Duration> 

—  time  remaining  fin  minutes)  to 
the  next  internal  event 

phase 

<Symbol> 

—  the  current  phase  (state) 

€ 

<  Duration> 

—  elapsed  time  in  the  current 
phase 

name 

parent 

processor 

inport 

outport 

pixmap 

X 

y 

sigma 

pheise 

e 

accessing  e 

e: 

phase 

phase: 

sigma 

sigma: 

X 

x: 

y 

y; 
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DEVS 

extTransFn.externallnput 

extTransition 

intTransFn 

intTransition 

outputEh 

outputFn 

restart 

timeAdvanceEli 

timeAdvanceFn 

displaying 

status 

initialize- release 

extent: 

tmttaltze 

initPoris 

macros 

continue 

holdIn.forTime: 

injpct:value: 

inject:value:eiapsedTime: 

noOutput 

passivate 

passivatein: 

sendrtoPort: 

port  creation 

t 

printing 

printOn: 

priniStnng 

private 

base  VisualComponent 

inport: 

outport: 

private-accessing 

name; 

parent 

parent: 

teXName 

private- logging 

views 

logExtTransFn 

loglntTransition: 

logOutputEh: 

logTimeAdvanceEh; 

view 

instance  creation 

makePair: 

new: 

logging  access 

isLogging 

logStream: 

teXFormai: 
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Appendix  B 

Application  Class 
Specifications 


Specifications  for  application  classes  are  provided  in  this  appendix.  These  classes 
are  in  the  CilP  Category  in  the  li.oage  st80-ClIP. 

The  classes  in  the  application  comp,  -uent  of  C£[P  are  subclasses  of  DEVS  clcisses 
and  are  shown  in  boldface: 
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Entities  [68] 

Models  [80] 

AtomicModel  [88] 

Dispatcher  [103] 

Equipment  [108] 

CuttingMachine  [114] 

AutomaticCutter  [116] 
BITECutter  [120] 
LaserCutter  [118] 
ManualCutter  [122] 
SpreadingMachine  [130] 

AutomaticSpreader  [132] 
Table  [124] 

CuttingTable  [128] 
SpreadingTable  [126] 
Planner  [99] 

CoupledModels  [82] 

OigraphModels  [84] 

DynamicDigraphModels  [86] 
Room  [92] 

CuttingRoom  [96] 
Warehouse  [94] 

Processors  [69] 

Coordinator  [73] 

DynamicCoordinator  [75] 
RootCoordinator  [77] 

Simulators  [71] 

The  format  corresponds  to  that  described  in  Appendix  A. 
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DigraphModels  subclass: 


Room 


A  Room  is  a  component  of  a  plant. 
Instance  Variables: 
equipment 
layout 


— ike  equipment  in  this  room. 

— ike  layout  of  the  room — a  de¬ 
scription  of  the  room ’s  si:e  and 
shape  and  the  location  of  each 
piece  of  equipment  in  the  room. 


name 

parent 

processor 

inpori 

outport 

pixmap 

receivers 

infiuencees 

pnoniyList 

compositionTree 

infiuenceDigraph 

seleciFn 

accessing 


getChildren 

getinfiuencees. 

geiReceivers: 

infiuencees: 

priorityList: 

receivers: 

select: 

translate 
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DEVS 


displaying 
initialize*  release 


port  creation 
printing 

private 


private-accessing 


private-logging 

views 


addCouple:pori:connectedTo:port: 

buildCompositton  Tree: 

compostitonTree 

connect.io: 

geiChtldren 

getinfluencees: 

getReceivers: 

select: 

seleciFn: 

setExtInpCoup:conneci:to: 
setExtOutCoup:  connect.io : 
sei[niCoup:portName:to:poriName: 
specifyCkildren: 

translate.model: 

state 

extent: 

initialize 

initPorts 

t 

pnntOn: 

prtntStnng 

base  VisualComponent 

inport: 

ontpori: 

name: 

parent 

parent: 

tcXName 

xsLogging 

view 


instance  creation 
logging  access 


new: 

isLogging 

logStream: 

teXFormat: 
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Room  subclass: 

Warehouse 


A  Warehouse  :s  that  portion,  of  a  plant  that  is  responsible  for  receiving  materials, 
maintaining  stored  items,  and  delivering  materials  to  organizations  both  inside 
and  outside  the  plant. 


name 

parent 

processor 

inport 

outport 

pixmap 

receivers 

influencees 

priorityList 

compositionTree 

influenceDigraph 

selectFn 

accessing  getCkildren 

getinfluencees 

get  Receiver  s.- 

influencees: 

priorityList: 

receivers: 

select: 

translate 
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DEVS 


displaying 

initialize-release 


port  creation 
printing 

private 


private-accessing 


private-logging 

views 


addCouple:port:connectedTo:pori: 

butldCompostiioJiTree: 

composUionTree 

connect.to: 

getChtldren 

geilnfiuencees: 

getReceivers: 

select: 

selectFn: 

setExiInpCoup:connect:to: 

setExtOutCoup:conneci:io: 

setIntCoup:portName:io:portName: 

specifyChtldren: 

translaie:model: 

state 

extent: 

initialize 

tniiPorts 

i 

print  On: 

printstring 

base  VisualComponent 

tnport: 

outpori: 

name: 

parent 

parent: 

teXName 

isLogging 

view 


instance  creation  new: 

logging  access  isLogging 

logSiream: 

ieXFormat: 
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Room  subclass: 


CuttingRoom 


A  CuttingRoom  is  a  facility  comprising  the  resources  needed  to  cut  fabric:  equip¬ 
ment,  operators,  and  materials.  An  instance  is  a  digraph  model  that  comprises 
a  planner,  a  dispatcher  for  operators,  a  dispatcher  for  materials,  and  equipment 
such  as  spreaders  and  cutters. 

The  relationships  between  the  various  pieces  of  equipment  must  be  specified  ex¬ 
plicitly.  The  relationships  between  the  planner  and  dispatchers  are  defined  au¬ 
tomatically  at  instance  creation. 

Instance  Variables: 

oscar  <  ..nner>  — A  planner  that  oversees  execu¬ 

tion  of  a  plan.  The  plan  desig¬ 
nates  how  resources  are  routed 
to  equipmet  for  various  tasks. 
The  planner  com¬ 

ponent  is  named  after  Oscar 
Estes,  the  cutting  room  man¬ 
ager  at  Jantzen  in  Seneca,  SC, 
who  helped  us  with  this  project. 
breakArea  <Dispatcher>  — A  dispatcher  of  the  operators  in 

the  cutting  room.  An  operator 
IS  always  routed  to  the  model 
for  the  equipment  to  which  he 
IS  next  assigned.  When  an  op¬ 
erator  IS  off-duty,  then  he  is 
routed  back  to  the  dispatcher. 

dropArea  <Dispatcher>  — A  dispatcher  of  the  materials  in 

the  cutting  room.  An  material 
IS  always  routed  to  the  model 
for  the  equipment  to  which  it  is 
next  used. 

equipments  <Set>  — The  equipment  available  for 

use  in  the  cutting  room. 

Testing: 

"instance  creation  test.." 

[  CuttingRoom  el  e2  equipment  huey  dewey  louie  operators  materials  | 

el  :=  Equipment  makePair:  ’El’. 

e2  :=  Equipment  makePair:  ’E2’. 

equipment  :=  OrderedCollection  with:  el  with:  e2. 


huey  Operator  new  name:  ’Huey’. 

dewey  :=  Operator  new  name:  ’Dewey’. 

louie  :=  Operator  new  name:  ’Lome’. 

operators  :=  Set  with:  huey  with:  dewey  with:  loute. 

materials  :=  Set  with:  (Material  new). 

cuiiingRoom  :=  CuttingRoom  makePair:  'Test  CR’  containing:  equipment 
operators:  operators  materials:  materials. 

CuttingRoom 


name 

parent 

processor 

inport 

outport 

pixmap 

receivers 

influencees 

priontyLisi 

compositionTree 

influence  Digraph 

selectFn 

Oscar 

breakArea 

dropArea 

equipments 

plan _ 

breakArea 
dropArea 
equipment 
oscar 
plan: 
restait 
stale 

containing:operators:materials: 
iniiPorts 

printOn: 
printstring 
base  VisuaiComponent 
inport: 
outport: 


accessing 


DEVS 

displaying 

initialize-release 

port  creation 
printing 

private 
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private-accessing  name: 

parent 

parent: 

ieXName 

private-logging  tsLoggtng 

views  View 

instance  creation  makePair:containing:operators:maierials 

logging  access  tsLoggtng 

logSiream: 

teXFormai: 


AtornicModel  subclass; 


Planner 


.4  planner  is  a  model  that  distributes  a  plan  to  other  models.  The  plan  is  specified 
before  simulation  begins.  ,4  planner  has  N  output  ports,  labeled  ^planl,  upland. 

planN  that  can  be  used  to  connect  to  other  models.  The  value  of  ,V  is  specified 
on  instantiation  and  may  not  be  changed. 


done 

- 1  Planner  - 

start 

result 


plan1 


plan2 


planN 


A  planner  also  tracks  the  completion  of  work  assignments  in  the  plan.  ,4  work 
assignment  arriving  on  the  #done  port  is  logged  as  completed  as  of  the  time 
>f  Us  arrival.  When  all  work  assignments  are  completed,  then  the  plan  and 
statistics  are  emitted  on  the  jjiresult  port. 


A  planner  has  (N+2)  states,  numbered  0  through  (N+l).  Stale  0  indicates  that 
no  plan  has  yet  been  received.  State  I  (  1  <=  I  <=  N)  indicates  the  plan  is  to 
be  output  on  port  #planl.  State  (N+l)  is  a  tracking  state  m  which  information 
about  completed  tasks  arriving  on  the  #done  input  port  is  recorded. 


The  output  ports  are  represented  by  an  array  collection  so  that  the  names  can 
be  matched  with  states — the  first  element  is  #planl,  the  second  ffplani,  and  so 
on. 
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state  variables: 

sigma  =  infinity  —  nothing  happens  until  a  plan  ami  es  {on  ^ start  ; 

phase  —  0  —  signifies  that  a  plan  has  not  get  armed 

plan  =  mi 

external  transition  function: 


case  input-port 

start: 

store  plan 
hold  in  I  for  0 

done: 

record  task  completion 
continue 

else 

error 

internal  transition  function: 
case  phase 

1:  2 


3 


N:  ^tracking 

output  function: 

if  (  phase  ^tracking  ) 

send  plan  io  port  ^plan(phase) 


plan 

<Ptan> 

Instance  variables: 

— the  plan  to  be  disper.sed 

n 

<Integer> 

—  the  number  of  output  ports,  cr- 

results 

<Statistics> 

eluding  /jtrr.suU 

—  the  statistics  associated  titl/t 

port 

<Symbot> 

the  plan 

—  the  name  of  the  port  io  which 

the  plan  should  be  sent,  ml  if 
none. 
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Testing: 

Planner  makePair:  ’Test  Planner’  outportCount  3 

"The  following  is  a  stand-alone  test  of  this  model  (see  pp.  82fJ  “ 
"Inspect  p  after  each  of  the  statements  below  to  perforin  the  test." 

I  p  plan  wal  wa&  wa3  j 
p  Planner  new:  'Planner' 
p  outportCount:  3. 


plan  :=  Plan  new. 

wal  ;■=  WorkAssignment  new. 

wa2  :=  WorkAssignment  new. 

wa3  :=  WorkAssignment  new. 

plan  add:  wal;  add:  wa2;  add:  wa3. 

p  plan:  plan. 

p  restart,  self  halt. 


p  intTransition. 
p  outputEh. 
p  intTransition. 

p  outputEh. 
p  intTransition. 
p  outputEh. 
p  intTransition. 


“(jjlplanl,  plan)" 

"state:  (sigma  =■  0,  phase  =  i?,  plan  ~  plan 
X  =  (#start,  plan),  y  =  (fjiplanl,  plan)" 
"(#plan2,  plan)" 

"(^planS.  plan)" 


p  inject:  #done  value:  wal  elapsedTime:  1. 
p  inject:  #done  value:  wa2  elapsedTime:  2. 
p  inject:  #done  value:  wa3  elapsedTime:  3. 


name 

parent 

processor 

inport 

ouiport 

pixmap 

X 

y 

sigma 

phase 

e 

plan 

n 

results 
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accessing 

outportNumber: 

DEVS 

plan 

plan: 

statistics 

extTransFn:extemalInput: 

displaying 

intTransFn 

outpiitFn 

restart 

status 

initialize-release 

initPorts 

macros 

outportCount: 

continue 

port  creation 

holdln:forTtme: 

injecV.value: 

tnjeci:valiie:elapsedTtme: 

noOutpui 

passivaie 

passtvatein: 

send:toPori: 

f 

printing 

printOn: 

private 

printSirtng 

base  VisualComponent 

private<accessing 

tnpori: 

outport: 

name: 

private- logging 

parent 

parent: 

leXName 

logExtTransFn 

views 

logJntTransitton: 

logOutpniEh: 

logTimeAdvanceEh: 

view 

instance  creation  makePair:outportCount: 

logging  access  isLogging 

logStream: 

teXFormat: 
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AtomicModel  subclass; 


Dispatcher 


I 

1 


A  Dispatcher  is  a  model  component  that  manages  a  pool  of  resources,  dispatching 
a  resource  to  another  model  in  accordance  with  some  plan.  A  dispatcher  has  2 
input  ports,  #plan  and  #in,  and  N  output  ports:  #outl,  fjtoutS,  ^ouiN. 
Pori  #plan  is  an  input  port  on  which  a  plan  is  to  be  received  that  drives  the 
routing  of  resources  to  and  from  the  dispatcher.  Resources  arrive  on  port  #tn 
and  are  dispatched  to  other  models  on  an  #oui*  port. 


plan 


- 1  Dispatcher  j - 

plani 

plan2 

planN 

Each  output  port  is  assumed  to  be  routed  to  one  model.  The  association  between 
model  and  output  port  is  stored  in  a  dictionary  (mapping Dictionary)  and  is 
established  at  instance  creation  using  the  models  provided.  For  example,  if  the 
models  are  (ml  m2),  then  an  association  between  #outl  and  ml  and  between 
#out2  and  m2  is  made.  When  a  resource  arrives  on  #in,  and  the  plan  reflects 
that  the  resource  should  be  rouied  next  to  ml,  then  the  resource  is  output  on 
#outl  based  on  the  dictionary  association  of  ml  and  fj^ouil.  Care  must  be 
taken  to  preserve  correct  routing  in  the  model — that  «,  that  connections  are 
correct. 


Every  resource  must  be  able  to  answer  the  message  ’whereNext:  aPlan’  with  the 
next  work  assignment  the  resource  is  called  for.  An  answer  of  nil  decrgr.ates  that 
the  resource  has  no  more  uses  within  the  plan.  In  determining  the  next  model, 
a  resource  may  safely  assume  that  first  work  assignment  for  it  in  the  plan  is  the 
next  to  be  performed. 

Instance  variables: 


plan  <Ptan>  — The  plan  agatnst  which  re¬ 

sources  are  dispatched. 

mapping  Dictionary  <Dicttonary>  —A  dictionary  whose  keys  are 

workstations  and  whose  values 
are  output  port  names.  This 
IS  used  to  route  resources  to 
a  workstation  as  given  in  the 
plan. 

resources  <Set>  —A  set  of  the  resources  that  have 

not  yet  been  dispatched,  either 
because  they  have  no  work  des¬ 
ignated  to  be  done  or  because 
they  are  not  available  at  the 
current  time. 

readyResources  <RouitngTable>  — The  resources  that  are  ready 

for  dispatching,  keyed  by  the 
model  that  is  the  destination. 

doneResources  <ResourceCollection>^ Resources  not  needed  any  fur¬ 
ther  in  the  plan 
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Testing: 

"The  following  is  a  stand-alone  test  of  this  model  (see  pp.  82ff)." 

"Inspect  dispatcher  after  each  of  the  statements  below  to  perform  the  test." 

I  models  resources  plan  wal  waS  waS  ol  o2  o3  el  e2  dispatcher  \ 

ol  .=  Operator  new  name:  'ol';  yourself. 
o2  :=  Operator  new  name:  ’o2’;  yourself. 
o3  :=  Operator  new  name:  ’o3’;  yourself. 

el  ;=r  Equipment  new  name:  'el';  yourself. 
e2  :=  Equipment  new  name:  ’e2';  yourself. 

plan  :=  Plan  new. 

plan  startTime:  (SimulationTime  date:  (Date  today)  time:  (Time  now)), 
wal  :=  Work  Assignment  workstation:  (Workstation  at:  el)  operators:  (Set 
with:  ol)  task:  nil. 

wa2  :=  WorkAssignment  workstation:  (Workstation  at:  e2)  operators:  (Set 
with:  o2)  task:  nil. 

wa3  :=  WorkAssignment  workstation:  (Workstation  at:  el)  operators:  (Set 
with:  o3)  task:  nil. 

plan  add:  wal;  add:  wa2;  add:  waS. 

models  :=  OrderedCollection  with:  el  with:  e2. 
resources  :=  OrderedCollection  with:  ol  with:  o2  with:  o3. 
dispatcher  :=  Dispatcher  makePair:  'Big  D’  forModels:  models  for  Re¬ 
sources:  resources. 

dispatcher  initialize. 

dispatcher  inject:  #plan  value:  plan  elapsedTime:  0. 
dispatcher  intTransition. 
dispatcher  outputEh. 
dispatcher  intTransition. 
dispatcher  outputEh. 
dispatcher 

dispatcher  inject:  #in  value:  plan  elapsedTime:  0. 
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name 

parent 

processor 

inport 

outpori 

pixmap 

X 

y 

sigma 

phase 

e 

plan 

mappingD  iction  ary 
resources 
readyResources 
doneResources 


clock 


accessing 

doneResources 

outportNumber; 

portFor: 

readyResources 

resources 

DEVS 

extTransFn.exiemalInput: 

iniTransFn 

ouipuiFn 

restart 

displaying 

status 

initialize- release 

forModelsiforResources: 

initPorts 

macros 

continue 

holdIn.-forTime: 

inject:value: 

in}eci:value:elapsedTime: 

noOutpui 

passivate 

passivaiein: 

send:ioPort: 

operating 

check  Resources 
wakeup 

port  creation 

f 

printing 

printOn: 

private 

base  VisuatComponeni 

inpori: 

outport: 
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private-accessing  name: 

parent 

parent: 

teXName 

private- logging  logExtTransFn 

loglntTrausition: 

logOutputEh: 

logTimeAdvanceEh: 

views  view 


instance  creation  forModelsrforResources; 

.  make  Pair  ;for  Models:  for  Resou  rces : 

logging  access  isLoggtng 

logStream: 

teXFormat: 
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AtomicModel  subclass: 

Equipment 


Equipment  is  any  piece  of  machinery. 


Equipment 

done 

plan 

producj 

optrin 

optrOut 

madln 

madOut 

Equipment  has  behavior  such  that  if  it  has  a  work  assignment  in  the  plan  that 
is  still  "to  do",  and  sufficient  resources  and  operators  are  available  to  perform 
the  work  assignment,  and  the  workstation  for  the  assignmant  is  available,  then 
work  on  the  task  is  begun.  Upon  completion  of  a  work  assignment,  statistics 
are  emitted  on  the  #done  port,  the  product  is  emitted  on  the  ^product  port,  the 
operator(s)  who  performed  the  task  are  emitted  on  the  #optrOut  port,  and  the 
collection  of  materials  fwhai’s  left  of  them)  is  emitted  on  the  #matlOut  port. 

Every  piece  of  equipment  comprises  a  set  of  workstations.  For  this  class,  only 
one  workstation  can  be  active  at  a  time.  (See  subclasses  for  equipment  that  can 
support  multiple  active  workstations.) 

Each  piece  of  equipment  has  a  wait  area  at  which  idle  operators  and  materials 
wait  for  the  start  of  a  task  specified  in  a  work  assignment.  The  wait  area  is 
represented  by  instance  variables  ’waitingOperators’  and  ’waitingMaterials’. 

When  a  resource  arrives  at  equipment,  it  is  put  in  the  wait  area  and  then  a 
check  is  made  to  see  if  a  work  assignment  can  be  started  based  on  the  presence 
of  all  required  resources  in  the  wait  area  and  the  availability  of  the  workstation 
specified.  The  current  implementation  insists  that  work  assignments  be  started 
in  their  order  in  the  plan.  When  a  work  assignment  is  started,  eligible  operators 
not  selected  for  the  task  are  emitted  on  the  #optrOut  port.  [A  work  assignment 
may  specify  a  task  to  be  performed  by  any  one  of  a  set  of  operators.] 

Equipment  has  the  following  phases  and  transitions: 

^passive  => 
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^working  => 

#done  =>  [emtl  .‘•tatisUcs] 

^-product  =>  [emit  product  ] 
^optrOui  =>  [e.mti  busyOperators  ] 
#matlOut  •=■>  [emit  busy  Materials  1 
(back  to  #passtve  or  #worktng) 

Instance  Variables: 


109 


location 

name 

number 

status 

manufacturer 

serialNumber 


— the  location  of  the  equipment 
on  the  shop  floor. 

— the  descriptive  name  for  this 
equipment. 

—the  identification  number  as¬ 
signed  to  this  equipment. 

— an  indication  of  whether  the 
equipment  is  operable  or  avail¬ 
able  for  work  or  not. 

— the  equipment  manufacturer. 

— the  serial  number  for  this  piece 
of  equipment. 


(Simulation-related  entities:) 
clock 
plan 

toDo 

startClock 

current  WorkAssignment 
busy  Workstations 


busyOperators 
busy  Materials 
waitingOperators 
waiting  Materials 
product 
statistics 


—the  (global)  simulation  time 
— the  current  plan  under  simu¬ 
lation  (a  shallow  copy  of  the 
original) 

— the  portion  of  the  plan  for  this 
piece  of  equipment  that  is  not 
yet  started. 

— the  value  of  clock  when  work  on 
the  current  task  started. 

— the  current  work  assignment 
— the  workstations  currently  ac¬ 
tive  for  this  piece  of  equip¬ 
ment.  This  is  a  sorted  col¬ 
lection,  ordered  by  incren<^mg 
time  to  next  work  assignment 
completion.  An  instance  will 
have  at  most  one  busy  worksta¬ 
tion,  but  subclasses  might  have 
more. 

— a  collection  of  operators  busy  at 
this  equipment. 

— a  collection  of  materials  jn  use 
at  this  equipment. 

— a  collection  of  operators  wait¬ 
ing  for  workstation  availability. 
— a  collection  of  materials  wait¬ 
ing  for  workstation  availability . 
—  the  product  of  the  most  recently 
completed  task. 

— statistics  for  the  most  recently 
completed  work  assignment 


no 


The  methods  in  category  DEVS  default  to  model  a  piece  of  equipment  that  takes  5 
minutes  to  do  any  task.  The  product  is  a  string  of  the  form  ’Product  <time> 
where  <time>  designates  the  simulation  time  at  which  the  product  was  com¬ 
pleted. 

Testing: 

I  plan  wal  waS  wa3  oJ  o2  o3  equipment  | 

ol  :=  Operator  new  name:  ’ol  yourself. 
o2  :=  Operator  new  name:  ‘o2’;  yourself. 
o3  ;■=■  Operator  new  name:  'o3’;  yourself. 

equipment  :=  Equipment  new  name:  ’E’;  yourself, 
plan  :=  Plan  new. 

plan  startTime:  (SimulationTime  date:  (Date  today)  time:  (Time  now)), 
wal  :=  Work  Assignment  workstation:  (Workstation  at:  equipment)  oper¬ 
ators:  (Set  with:  ol)  task:  nil. 

wa2  :=  Work  Assignment  workstation:  (Workstation  at:  equipment)  oper¬ 
ators:  (Set  with:  o2)  task:  nil. 

waS  ;■=  Work  Assignment  workstation:  (Workstation  at:  equipment)  oper¬ 
ators:  (Set  with:  o3)  task:  nil. 

plan  add:  wal;  add:  wa2;  add:  waS. 

equipment  restart. 

equipment  inject:  #plan  value:  plan  elapsedTime:  0. 
equipment  inject:  #optrIn  value:  ol  elapsedTime:  0. 
equipment  intTransition. 
equipment  outputEh. 
equipment  intTransition. 
equipment  outputEh. 
equipment 

equipment  inject:  #in  value:  plan  elapsedTime:  0. 


Ill 


name 

parent 

processor 

inport 

outport 

pixmap 

X 

y 

sigma 

phase 

e 

location 

description 

number 

status 

manufacturer 

serialNumber 

clock 

plan 

startClock 
to  Do 

currentWorkAssignment 

busy  Workstations 

waitingOperators 

waitingMaterials 

product 

statistics 

accessing 


DEVS 


displaying 
initialize- release 


busy  Workstations 

description 

description: 

location 

manufacturer 

moveTo: 

number 

serialNumber 

waitingMaterials 

waitingOperators 

extTransFn.-extemalInput: 

intTransFn 

outputFn 

restart 

status 

initPorts 


112 


macros 


port  creation 

printing 

private 


private- accessing 


p  riva  t  e-  logging 


views 


continue 

holdIn:forTime: 

inject.v^'ut: 

inject:value:elapsedTimc : 

noOutput 

passivate 

passivateln: 

sendAoPort: 

priniOn: 

check 

plan; 

start:on:by:using: 

name: 

parent 

parent: 

teXName 

logExtTransFn 

loglntTransiiion: 

logOniputEh: 

logTimeAdvanceEh: 

view 


instance  creation 
logging  access 


makePair: 

new: 

is  Logging 

logStream: 

ieXFormat: 
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I 

I 


E'quipmenl  subclass. 

CuttiiigMachine 


A  Cutting  Machine  is  a  uiachtne  used  to  cut  fabric. 

Instance  Variables: 

fabrics  — the  fabrics  that  can  be  cut  by 

this  machine. 

maximumCutting Depth  — the  inaximurii  cutting  depth 

Class  Variables: 


name 

parent 

processor 

inpori 

outport 

ptxmap 

I 

y 

sigma 

phase 

e 

location 

description 

number 

status 

manufacturer 

senalNumber 

clock 

plan 

stariClock 

toDo 

current  Work  Assignment 

busy  Workstations 

waitingOperators 

waitingMatenals 

product 

statistics 

fabrics 

maximumCuttingPepth 
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accessing 


DEVS 


displaying 
initialize- release 


port  creation 

printing 

private 


private-accessing 


private- logging 


instance  creation 
logging  access 


fabrics 

fabrics; 

inaLXimuniCutiingUcplli 
inaximumCuttiiigDepth; 
extTransFn.exiemal  input: 
intTransF  n 
oulputFn 

restart 

status 

imtPorts 

continue 

hoJdln.forTime: 

inject.vatue. 

inject.'va/ue  .elapsed  J'l  me 

noOulput 

passivate 

passivaiein: 

send.toPori: 

printOn: 

check 

plan: 

start:on:by:using: 

name: 

parent 

parent: 

leXName 

logEztTransFn 

loglntTransition: 
logOutputEh: 
logTime  Advance  Eh: 


makePair: 

new: 

isLogging 

logStream: 

teXFormat: 


CuttingMachine  subclass: 

AutomaticCutter 


An  AutomaiicCutier  zs  a  cutter  whose  blade  is  under  computer  control. 


name 

parent 

processor 

inpori 

outport 

pixmap 

X 

y 

sigma 

phase 

e 

location 

description 

number 

status 

manufacturer 

serialJVumber 

clock 

plan 

stariClock 

ioDo 

current  Work  Assignment 

busy  Workstations 

waitingOperaiors 

waiting  Materials 

product 

statistics 

fabrics 

maximumCutting  Depth _ 

accessing  fabrics 

fabrics: 

maximumCuttingDepth 
maximumCutting  Depth: 
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DEVS 

extTransFniexiemaUnpul 

intTransFn 

ouipuiFn 

restart 

displaying 

status 

initiedize- release 

initPorts 

macros 

continue 
holdlniforTime: 
inject. -value: 

inject:value:elapsedTime: 

noOuiput 

passivate 

passivateln: 

send:ioPori: 

port  creation 

, 

printing 

printOn: 

private 

check 

plan: 

start:on:by:using: 

priArate-accessing 

name: 

parent 

parent: 

teXName 

private-  logging 

logExtTransFn 

loglntTransiiion: 

logOutpuiEh: 

logTimeAdvanceEh: 

views 

view 

instance  creation 

makePatr: 

new: 

logging  access 

isLogging 

logSiream: 

teXFormat: 
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AutomaticCutter  subclass: 

LaserCutter 


A  LaserCuiter  ts  a  cutter  in  which  a  laser  beam  is  used  to  cut  fabric. 


name 

parent 

processor 

tnpori 

outport 

pixmap 

X 

y 

sigma 

phase 

e 

location 

description 

number 

status 

manufacturer 

serialNumber 

clock 

plan 

siartClock 

ioDo 

current  WorkAssignment 

busy  Workstations 

waitingOperators 

waiting  Materials 

product 

statistics 

fabrics 

maximumCuttingPepth _ 

accessing  fabrics 

fabrics: 

maximumCuttingDepth 
maximumCutting  Depth: 
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DEVS 


displaying 

initialize-release 

macros 


port  creation 

printing 

private 


private-accessing 


private-logging 


views 


exiTransFn.exlerTtalInpul: 

iniTransFn 

outputFn 

restart 

status 

imiPorts 

continue 

koldIn:forTime: 

injeci:value: 

tnject:value:elapsedTime: 

noOutpui 

passivate 

passivatein: 

send:toPori: 

priniOn: 

check 

plan: 

start:on:by:using: 

name: 

parent 

parent: 

teXName 

logExiTransFn 

loglniTransition: 
logOutputEh: 
logTime  Advance  Eh: 
view 


instance  creation 
logging  access 


make  Pair: 
new: 

isLogging 

logStream: 

teXFormai: 


119 


I 


AutomaticCutter  subclass: 

BITECutter 


A  BITECutter  is  an  automatic  cutter  that  has  a  cutting  blade  mounted  on  a 
mechanism  that  allows  the  blade  to  be  moved  to  any  point  in  an  X-Y  coordinate 
system.  The  blade  is  controlled  by  digital  data  that  represents  a  marker.  The 
length  of  a  spread  to  be  cut  may  be  longer  than  the  table  for  the  cutter. 


name 

parent 

processor 

inport 

outport 

ptxmap 

X 

y 

sigma 

phase 

e 

location 

description 

number 

status 

manufacturer 

serialNumber 

clock 

plan 

siartClock 

toDo 

current  WorkAssignment 

busy  Workstations 

waiUngOperators 

waiting  Materials 

product 

statistics 

fabrics 

maximumCuttingPep^h 
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accessing 


DEVS 


displaying 

ini  tialize-releas  e 

macros 


port  creation 

printing 

private 


private-accessing 


private- logging 


views 


fabrics 

fabrics: 

maxtmumCuUingDeplh 

maxxmumCiittingDeptb: 

cxiTransFn-.cxtcrnallnput: 

xntTransFn 

outpuiFn 

restari 

status 

xnitPoris 

contxnue 

holdln:forTxme: 

inject:value: 

xnjeci:value:elapsedTime: 

noOutput 

passxvate 

passxvatein: 

stnd:ioPort: 

i 

printOn: 

check 

plan: 

start:on:by:usxng: 

name: 

parent 

parent: 

teXName 

logExtTransFn 

loglntTransiiion: 

logOuiputEh: 

logTimeAdvanceEh: 

viexv 


instance  creation 

makePaxr: 

new: 

logging  access 

isLogging 

logStream: 

teXFormat: 
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CuttingMachine  subclass: 

ManualCutter 


A  ManualCutter  is  a  cutter  whose  path  ts  controlled  completely  by  an  operator. 


name 

parent 

processor 

inport 

outpori 

pixmap 

X 

y 

sigma 

phase 

e 

location 

description 

number 

status 

manufacturer 

serialNumber 

clock 

plan 

startClock 

toDo 

current  Work  Assignment 

busy  Workstations 

waitingOperators 

waitingMaterials 

product 

statistics 

fabrics 

maximumCutting  Depth _ 

accessing  fabrics 

fabrics: 

maximumCutting  Depth 
maximumCuttingDepth: 


122 


DEVS 

exiTransFn:exiernalInput 

displaying 

tntTransFn 

oulpuiFn 

restart 

status 

initialize- release 

inttPorts 

macros 

continue 

port  creation 

holdIn.forTtme: 

inject:value: 

inject:value:elapsedTime: 

noOutput 

passivate 

passivateln: 

send:toPort: 

printing 

pnntOn: 

private 

check 

private-accessing 

plan: 

start:  on:by:using: 
name: 

private- logging 

parent 

parent: 

ieXName 

logExtTransFn 

views 

logint  Transition: 
logOutputEh: 
logTimeAdvanceEk: 
view 

instance  creation 

makePair: 

new: 

logging  access 

isLogging 

logStream: 

teXFormat: 
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Equipment  subclass; 

Table 


A  Table  is  a  raised,  flat,  rectangular  surface. 
Instance  Variables: 
height 
length 
width 


— the  height  of  this  table. 
— the  length  of  this  table. 
— the  width  of  this  tabic. 


Class  Variables: 


location 

description 

number 

status 

manufacturer 

sertalNumber 

clock 

plan 

startClock 

ioDo 

current  Work  Assignment 

busy  Workstations 

watitngOperaiors 

waiting  Materials 

product 

statistics 

height 

length 

width _ 

height 
length 
width 

exiTransFn:externalInpul: 
intTransFn 
outputFn 

restart 
initPoris 

printOn: 


accessing 

DEVS 


initialize- release 
printing 
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private  check 

plan: 

stari:on:by  .-using: 

views  vtew 

instance  creation  height:width;height: 
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Table  subclass: 

SpreadingTabIc 


A  SpreadingTabIc  is  a  table  on  which  fabric  is  spread,  either  manually  or  by 
using  an  automatic  spreader. 

Instance  Variables: 

Class  Variables: 


location 

description 

number 

status 

manufacturer 

serialNumber 

clock 

plan 

stariClock 

toDo 

current  Work  Assignment 

busy  Workstations 

watting  Operators 

watting  Materials 

product 

statistics 

height 

length 

width 

height 
length 
width 

extTransF  n:externallnpul: 
intTransFn 
outputFn 

restart 
initPorts 

printOn: 
check 
plan: 

start:on:by:ustng: 
view 


accessing 

DEVS 


initialize- release 

printing 

private 

views 


126 


Table  subchiss: 

CuttiiigTable 


.1  CulttngTabU  ts  a  table  on  which  fabric  is  cut.  either  rnauuali’j  ur  autornati- 
cally. 

Instance  Vanabks: 

cutters  -the  colUctlon  c/  ,  uttr  rs  that 

ca  n  be  used  at  iht>  tab  it 

Class  i'anabies: 


location 

description 

number 

status 

manufacturer 

serialNumber 

clock 

plan 

startClock 

loDo 

current  ITorit^siijrnrTietii 

busy  Workstations 

wailingOperators 

waiting  Materials 

product 

statistics 

height 

length 

width 

cutters _ 

accessing 

DEVS 


initialize- release 
printing 


height 

length 

width 

eztTransFn-ezlernallnpnt 

intTransFn 

outpuiFn 

restart 
mil  Forts 

prinlOn: 
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private 

check 

plan: 

start:  on:  by. using: 

TBS 

cutters 

cutters; 

views 

vtew 

instance  creation 

heighi:width:heighl: 
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Equipment  subclass: 

SpreadingMachine 


/I  spreading  machine  is  a  piece  of  equipment  used  for  spreading  The  model  has 

two 

Instance  Variables: 

mountedRoHs  —a  dictionary  of  the  mounted 

rolls.  The  key  is  some  desig¬ 
nation  of  a  mount. 

weighiLimits  — the  maximum  weight  that  a  roll 

mount  can  support,  in  pounds. 

sizeLimtls  — the  maximum  roll  diameter 

that  a  roll  mount  can  hold. 

The  last  two  attributes  are  ignored  in  this  implementation. 

Class  Variables: 


location 

description 

number 

status 

manufacturer 

sehalNumber 

clock 

plan 

startClock 

toDo 

current  WorkAssignment 

busy  Workstations 

waitingOperators 

waitingMaienals 

product 

statistics 

mountSymbols 

mountedRoHs 

weightLimits 

sizeLimits 

spread  Rates 

ret  I  irnRate _ 
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accessing 


DEVS 


initialization- release 
initialize-  release 
operating 


printing 

private 


views 


mountSymbols 
return  Rate 
returnRate. 
spread  Rates: 

exiTransFn.exiemalInput: 

intTransFn 

outputFn 

restart 

initialize:weightLimits:sizeLimits:spreadRati 

tmtPorts 

clearOut 

mount: 

mountron: 

remove: 

removeRoll: 

respondTo: 

spread  RateFor: 

printOn: 

check 

plan: 

start:on:by:ustng: 

view 


instance  creation 


new: 

new:spread  Rates: 

new:  weightLimits:sizeLimits:spread  Rales: 
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SpreadingMachine  subclass: 

AutomaticSpreader 


i4n  AutomaticSpreader  is  a  machine  that  can  be  attached  to  a  spreading  table 
and  used  to  spread  fabric.  Fabric  (in  rolls  or  other  form)  are  attached  to  the 
spreader.  The  spreader  then  spreads  the  fabric  in  a  single  ply. 

Instance  Variables: 

Class  Variables: 

location 
description 
number 
status 

manufacturer 
senalNumber 
clock 
plan 

startClock 
toDo 

current  Work  Assignment 
busy  Workstations 
waitingOperators 
waiting  Materials 
product 
statistics 
mountSymbols 
mountedRolls 
weightLimits 
sizeLimits 
spreadRates 
retumRate 
accessing 


DEVS 


initialization-release 


mountSymbols 

retumRate 

retumRate: 

spreadRates: 

extTransFn-.extemalInput: 

intTransFn 

outputFn 

restart, 

initialize:weightLimits:si:eLimits:spreadRates: 
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initialize-release 

initPorts 

operating 

clearOui 

mount: 

mount.on: 

remove: 

removeRoll: 

respondTo: 

spreadRaieFor: 

printing 

printOn: 

private 

check 

plan: 

start  :on:by  .using: 

views 

view 

instance  creation 

new: 

new:spreadRates: 

new:w€tghtLiTmls:sizeLimits:spreadRates: 
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Appendix  C 


Test  Class  Specifications 


The  classes  whose  specifications  appear  in  this  appendix  are  used  for  testing. 
They  correspond  to  the  generator,  transducer,  and  simple  processor  models 
described  by  Zeigler.  Not  only  are  these  classes  useful  for  testing,  they  are  also 
useful  as  a  model  for  writing  application  classes. 

The  classes  in  the  testing  component  of  CHP  are  subclasses  of  DEVS  classes 
and  are  shown  in  boldface: 

Entities  [68] 

Models  [80] 

AtomicModel  [88] 

GeneratorModels  [135] 
SimpleProcessorModel  [139] 
TransducerModels  [137] 

CoupiedModels  [82] 

DigraphModels  [84] 

Processors  [69] 

Coordinator  [73] 

RootCoordinator  [77] 

Simulators  [71] 

The  format  corresponds  to  that  described  in  Appendix  A. 

The  end  of  this  appendix  provides  text  that  can  be  used  to  run  a  simulation 
(see  Section  3.5). 
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AtomicModel  subclass: 

GeneratorModels 


This  class  implements  the  model  described  by  Zeigter  in  section  5.1.1. 
Instance  variables: 

next  Job  Number  — 

interamvalTime  — 


name 
parent 
processor 
inport 
outport 
pixmap 

X 

I 

sigma 

phase 

■ 


nextJobNumber 

interarrivalTime 


accessing 

interarrivalTime 

interarrivalTime: 

DEVS 

exiTransFn:extemallnput: 

intTransFn 

outputFn 

restart 

displaying 

status 

initialize- release 

iniiPorts 

macros 

continue 

holdIn.forTime: 

in]ect:value: 

injecUvalue.elapsedTime: 

noOutput 

passivate 

passivateln: 

send:ioPort: 

port  creation 

f 

printing 

print  On: 
printstring 
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private 

private-accessing 
private- logging 

views 


base  VisualComponeni 

tnpori: 

outport: 

nextJobName 

nextJobNumber 

nextJobNumber; 

logExtTransFn 

loglntTransttton: 
logOuiputEh: 
logTime  Advance  Eh: 
view 


instance  creation 

makePair:interarrivalTime. 

new: 

newrinterarrivalTime: 

logging  access 

tsLoggtng 

logStream: 

teXFormai: 
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AtomicModel  subclass: 

TransducerModels 


This  class  implements  the  models  descnbed  by  Zeigler  in  section  5.1-2. 
Instance  variables: 

observationlnterval  — 

arrivedList  — 

solvedList  — 

clock  <Duration>  — Total  time  elaps'd  in  the  run 

totalTa  — 


name 

parent 

processor 

inpori 

outport 

ptxmap 

X 

y 

sigma 

phase 

e 

observationlnterval 

arrivedList 

solvedList 

clock 

totalTa 

arrivedList 
arrivedList; 
clock 
clock: 

observation  Inter  val : 
solvedList 
solvedList: 
totalTa 
totalTa: 

extTransFn-.externalInput: 
iniTransF  n 
outputFn 
restart 


accessing 


DEVS 
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displaying 

status 

initialize*  release 

tnttPoris 

macros 

continue 

holdln.forTime: 

injeci:value: 

in)ect:vaiue:elapsedTime: 

noOutpui 

passivate 

passivatein: 

port  creation 

senditoPori: 

t 

printing 

private 

print  On: 

pnniStnng 

base  VisualComponent 

inport: 

outport: 

private-accessing 

name: 

private-logging 

parent 

parent: 

teXName 

logExtTransFn 

loglntTransition: 

logOutputEh: 

logTimeAdvanceEh: 

views 

view 

instance  creation 

makePair:observationInlerval : 

new: 

new;observationlntervai: 

logging  access 

isLogging 

iogStream: 

teXFormat: 
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AtomicModel  subclass: 


SimpleProcessorModel 


This  class  implements  the  model  described  by  Zetgler  in  section  -/.i. 

Instance  variables: 

jobID  — 

processtngTime  — 

Testing: 

This  te.i,  is  taken  from  Zeigler,  p.  8Sff.  State  is  listed  as:  (sigma  phase  }ob-id 
processing- time) 

I  p ! 

p  :=  SimpleProcessorModel  makePair:  ’P’  processtngTime:  5  minutes, 
p  restart. 

"a"  p  x:  (Content  port:  (p  ,  #in)  value:  ifxl). 

"b"  p  e:  0  minutes. 

"c"  p  extTransition.  “State:  (5  #busy  5/' 

“d"  p  outputEh. 

"e"  p  intTransition.  “State:  (INF  ^passive  #z]  JJ" 

P- 

"i"  p  inject:  (p  ,  #in)  value:  yxl  elapsedTime:  0  minutes. 

"j"  p  inject:  (p  ,  #in)  value:  #z2  elapsedTime:  3  minutes. 

"k"  p  outputEh. 

"I"  p  intTransition.  “State:  (INF  passive  ffxl  5)“ 

name 

parent 

processor 

inport 

outport 

pixmap 

x 

y 

sigma 

phase 

e 

jobID 

processingTime _ 


accessing 

jobID 

jobID: 

processingTime 

processingTime: 

DEVS 

extTransFn.exiemalInput: 

iniTransFn 

ouipuiFn 

restart 


displaying 

status 

initialize-  release 

initPorts 

macros 

continue 

holdIn:forTime: 

injeciivalue: 

inject  .value.elapsedTime: 

noOutput 

passivate 

passivateln: 

senditoPort: 

port  creation 

f 

printing 

printOn: 

printstring 

private 

base  VisualComponeni 

tnpori: 

outpori: 

private-accessing 

name: 

parent 

parent: 

teXName 

private- logging 

logExtTransFn 

loglntTransition: 

logOutputEh: 

views 

logTimcAdvanccEh: 

view 

instance  creation 

makePair:processingTime: 

new: 

logging  access 

new:processingTime: 

isLogging 

logStream: 

ieXFormat: 
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This  is  the  text  of  file  “simple  test.” 

•C\tt  "}siiBple  test{\tt  "} 

I  genr  trautsd  p  ef  efp  rl 

{\tt  "}Processors  teXFormat:  tnie.'(\tt  "> 

Processors  logStream:  ‘simp. log'  asFileaame  writeScream. 

{\tt  "}Processors  logStream:  nil.-C\tt  "}  {\tt  "}Close  the  log  stream — later!  !-{\tt  "} 

genr  :=  GeneratorModels  makePair:  'GENR'  interarrivalTime;  10  minutes, 
tremsd  :=  TransducerHodels  makePair:  'TRAHSD'  observationinterval :  100  minutes, 
p  :=  SimpleProcessorModel  makePair:  'P'  processingTime;  5  minutes. 

ef  :=  (DigraphModels  makePair:  'EF'). 
ef 

inport:  #(in): 
outport;  #(result  out); 

specifyChildren:  ( (OrderedCollection  new)  add:  genr;  add:  transd;  yourself); 
{\tt  "jExternal  input  coupling. . {\tt  "} 

addCouple:  ef  port:  tin  connectedTo:  treinsd  port:  tsolved; 

{\tt  "jExternal  output  coupling .. {\tt  ")• 

addCouple:  genr  port:  tout  connectedTo:  ef  port:  tout; 

addCouple:  transd  port:  tout  connectedTo:  ef  port:  tresult; 

{\tt  "}Internal  coupling . .{\tt  "} 

addCouple:  genr  port:  tout  connectedTo:  tramsd  port:  tariv; 
addCouple;  transd  port:  tout  connectedTo:  genr  port:  tstop. 

efp  ;=  (DigraphModels  makePair:  'EF-P'). 
efp 

inport ;  t ( ) ; 
outport:  t(out); 

specifyChildren:  ((OrderedCollection  new)  add:  p;  add;  ef;  yourself): 
priorityList;  (  (OrderedCollection  now) 
addFirst:  p; 

addLast;  ef;  yourself  ); 

{\tt  "}External  input  coupling.  . {\tt  ")■ 

{\tt  "jExternal  output  coupling ..  {\tt  ")• 

addCouple;  ef  port;  tresult  connectedTo:  efp  port;  tout; 

■C\tt  "Jlnternal  coupling.  .{Xtt  ")• 

addCouple;  p  port:  tout  connectedTo:  ef  port:  tin; 

addCouple:  ef  port:  tout  connectedTo:  p  port;  tin. 

r  :=  (RootCoordinator  new;  'RC'), 
r 
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startTime:  (SimulationTime  date;  (Date  today)  time;  (Tirae  JromSecorids 
tiaeLimit;  r  startTime  +  110  minutes; 
liakToParent :  (efp  processor). 

SimulationfiunView  tryOn:  r. 


M2 
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